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Where's the Party? 




ow is not the best time in 
the world to be a third- 
party game developer. 
Whereas in the past the 
natural rhythms of game 
industry cycles and fortunes mirrored 
big-bang-big-crunch cycles of consolida- 
tion and start-ups, the game industry is 
now large enough that a long-range fore- 
cast of continued consolidation seems 
more likely. 

Going first-party will provide only 
short-term security for some developers if 
the next year sees a major shakeout 
among publishers, as analysts are begin- 
ning to predict will happen. Second par- 
ties barely exist as such anymore, most 
of the prominent ones having been fully 
absorbed or cut loose by their publishers 
in this console cycle. 

Is the industry headed for a shakeout 
in 2003? If there's one thing to learn 
from games, it's that very few match-ups 
don't end up with winners and losers. 
Consolidation has been a consistent fea- 
ture of the maturing of most other enter- 
tainment media, and currently the odds 
don't seem good that we will see as many 
game publishers at the end of 2003 as 
there are today. Those that go down will 
take their first-party studios with them, 
leaving some developers in unfamiliar 
hands through mergers and acquisitions, 
and leaving others out in the cold entire- 
ly. Developers and publishers in all three 
major markets — Japan, North America, 
and Europe — continue to face unique 
but significant challenges in their respec- 
tive economies. 

The hardware makers are holding — 
and exerting — an increasing amount of 
power, making tycoons out of winners 
and paupers out of losers. On the devel- 
oper end of the food chain, budgets are 
being clamped down and plum projects 
seem to be harder to come by, even for 



those studios for whom they used to 
come relatively easy. If you now work for 
a small studio and the name printed in 
the corner of your paychecks hasn't 
changed to that of a larger company in 
the past couple of years, you could be in 
for a bumpy ride. 

New this month. This issue features the 
debut of a new editorial property. Game 
Developer Mobile. So much information 
is swirling around the nascent industry of 
games for mobile devices that we've set- 
tled on a newsletter format, with report- 
ing and analysis from Ben Calica, a veter- 
an game industry writer and analyst. Our 
goal is to cut through the hype with an 
independent perspective, while providing 
the most relevant, up-to-date information 
and trends in a context that keeps devel- 
opers' issues and concerns at the fore- 
front. Look for this new feature bi- 
monthly, and be sure to let us know what 
kinds of news and information you'd like 
to see in future editions by e-mailing us at 
editors@gdmag.com. 

The next 12 months will be crucial 
for mobile game developers. In order to 
carve out a successful role in this mar- 
ket, game developers must provide their 
clients real value in the form of well- 
executed games, while asserting their 
strategic value in a market where most 
business deals remain ad hoc and few 
workable standard models have 
emerged. Handset manufacturers and 
mobile operators seem convincingly 
committed to supporting a market for 
games; let's hope they give developers 
enough leverage and incentive to make 
good ones. 
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^INDUSTRY WATCH 



KEEPING AN EYE ON THE GAME BIZ | e v e r a r d stroni 



No more Mr. Nice Box. Microsoft has 

no plans to ease up on its efforts to 
carve out a position in the $10 bilHon 
videogame market, rather than cutting 
its losses and exiting from the venture. 
Industry analysts expect Microsoft to 
spend more than $2 billion in the next 
five years on the Xbox. Microsoft's 
Xbox Live broadband service has seen 
early success, with a reported 150,000 
kits sold in the first week of release. 

Metis brands Acclaim. Marc Metis has 

joined Acclaim Entertainment as its new 
senior vice president of brand. In his 
position, he will manage Acclaim's fran- 
chises and new brands. 

No rust in Activision deal with 

Stainless Steel. Known for the PC 
strategy title Empire Earth, Stainless 
Steel Studios has signed an exclusive 
multi-title, multi-year agreement with 
Activision. Their first title will be anoth- 
er historical RTS game. 

NewKidCo posts loss. Due to the 

delayed release of two titles — Little 
League Baseball 2002 (GBA) and Tom 
& Jerry War of the Whiskers (PS2) — 
NewKidCo announced an operating loss 
of $2.4 million for Q3 2002, compared 





Empire Earth developers Stainless Steel Studios 

to a $607,000 operating loss for the 
same period in 2001. 

PC game sale revenue up for 2002, 
but unit volume down. NPDTechworld 

revealed that PC game revenues were up 
1.2 percent — from $945 million for the 
first 10 months in 2001 to $956 for that 
same time period in 2002 — but the 
number of units sold fell by 6.2 percent, 
from 44.4 miUion in 2001 to 41.6 mil- 
lion for those same 10 months in 
2002. The research also pointed 
out that the average selling price 
of PC games rose from $32 in 
2001 to $37 in 2002, but it did not say i 
this price increase caused the lower vol- 
ume of unit sales or if there were other. 



have signed a multi-title deal with Activision. 

outside factors, such as increased compe- 
tition from the console industry or other 
broader economic trends. 

Take-Two takes its own Angel. Take 

Two has acquired Angel Studios, develop- 
ers of Midnight Club and Smuggler's 
Run, for an aggregate $28 million in cash 
and around 235,000 shares of restricted 
common stock. Angel Studios will now 
be known as Rockstar San Diego. 

Send all industry and product 
news to neivs@gdmag.com. 




DEVELOPMENT SOFTWARE^ HARDWARE 
AND OTHER STUFF 



Calculate game royalties and pay- 
outs. PLX Systems introduced a new 
royalty accounting and licensing system 
for large game pubHshers. The product, 
PLXware Right Track Suite 
(PLXware/RTS), can be used to process 
royalties for authors, artists, com- 
posers, producers, and other rights- 
holders. www.plxsystems.com 

New tree creation software. IDV 

recently released SpeedTreeRT, a tree 
creation tool for game and visual simu- 
lation development. The program deliv- 
ers low-polygon, realistic trees, with 



adjustable wind effects, seamless LOD 
transitions, and a library of over 90 
trees from 30 core species. 
www.idvinc.com 

New Intel C++ compiler. Intel's 

newest C++ compiler, version 7.0, 
integrates with Microsoft Visual 
Studio, and the Linux version provides 
GNU compatibility to C++. The com- 
piler also include an auto-paralleliza- 
tion option that automatically looks 
for opportunities in applications to 
create multiple execution threads. 
www.intel.com 



PCOMI NG EVENTS 



GAME DEVELOPERS 
CONFERENCE 

San Jose Convention Center 

San Jose, Calif. 

March 4-8, 2003 

Cost: $150-$1, 975 

www.gdconf.com 

GDC MOBILE 
San Jose Convention Center 
San Jose, Calif. 
March 4-5, 2003 
Cost: $895 

www.gdcnnobile.conn 

MILIA (NEW DATES) 
Palais Des Festivals 
Cannes, France 
March 26-28, 2003 
Cost: variable 
www.nnilia.conn 
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THE SKINNY ON NEW TO 




New Worlds, New Battlefields: 
Massively Multiplayer Online 
Game Middleware 



C 



reating a massively multi- 
player online game is 
game development's equiv- 
alent of a moon shot. It's 
expensive, technically dif- 
ficult, and can take years to complete, 
and yet everyone wants to give it a try. 

The technology required is not easy for 
newcomers to develop. Sensing the need 
for software that handles a variety of 
functions, including billing, patching, 
support, administration, client messag- 
ing, stable servers, data persistence, and 
server clusters, several companies are 
developing middleware libraries and 
products to ease these hurdles. 

Butterfly.net and Zona's Terazona are 
two products that provide nearly com- 
plete MMOG solutions. Both supply the 
skeleton of an MMOG, leaving only the 
skin of a graphics engine, a billing sys- 
tem, and the guts of the actual game 
mechanics to be defined. 

Taken at the highest level, Butterfly.net 
and Terazona use the same solution strat- 
egy. The details are different enough that 
the environment and personality of the 
developer will clearly suggest one over the 
other. Their highest-level strategy is not 
appropriate for all future MMOGs, how- 
ever, and whether you would use 
Butterfly.net or Terazona depends on if 
your game fits into their mold. 

Common Parts of the 
High- Level Design 

I essaging to dispatcher or gateway. 

I Both systems have a simple API to 
connect, validate an account, get avail- 
able game characters, and connect with a 



by mitch ferguson and michael ballbach 




A simplified version of Butterfly.net and Terazona architecture. 



particular character. This uses a client- 
server messaging system, which is easily 
extensible, reliable, and simple to inte- 
grate into a game client. 

Game servers and their landscape. The 
developer divides up their world into 
fixed sections, with the size of each sec- 
tion dependent on how much action is 
expected to occur there. The actor/object 
positioning and landscape collision for 
each section is simulated on a single serv- 
er. There can be multiple sections on a 
single server, but there cannot be multiple 
servers for a single section. These section 



servers are the final destination of the 
game client messages. The boundaries 
between these world locations are imple- 
mented in different ways for Butterfly.net 
and Terazona, but both make information 
about things on the other sides of these 
boundaries available to the game client. 

These servers are divided into two 
separate halves: the generic landscape 
functionality and the game-specific 
mechanics. The developer writes the 
game-specific mechanics to take care of 
the simple rules such as trading, group- 
ing, and targeting. In addition, the devel- 



MITCH FERGUSON I Mitch was a lead engineer on Maxis's The Sims Online and 
Jaleco's Lost Continents, and now works for a MMO startup in San Francisco called 
Perpetual Entertainment. 

MICHAEL BALLBACH I Mike has been a server engineer at VRl/ Jaleco for six years, 
was the lead server engineer on Jaleco's LOST Continents, and now works for Perpetual 
Entertainment. 



www.gdmag.com 
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oper must write a separate process that 
simulates monsters. 

Game-specific mechanics. Messages 
from the cUent are forwarded to the 
game-specific functionaUty in case special 
physics or movement rules are in play. 
Butterfly.net has you write this code in 
Python, which is interpreted by the built- 
in interpreter. Terazona asks that you 
link in a shared library to receive these 
callbacks. Either way, this rule-checking 
code is used to vaHdate game state and 
client messages. 



NPCs and monsters. When it comes to 
monster AI, both systems pass the buck. 
Terazona has NPC servers connect as a 
privileged game client. Butterfly.net has a 
separate NPC server for every section. In 
both cases the developer is in charge of 
how these separate servers are designed 
and coded. There is an API for receiving 
callbacks and sending messages to the 
landscape and the game clients. 

Persistence. The player data structure 
(or parts of it) is automatically persisted 
by both systems. Butterfly.net requires 



Selecting Networking 
Middleware 

When considering networking middle- 
ware, things aren't as straightfor- 
ward as you may think. Networking is not 
just a numbers game; you can't look at fill 
rate and rendering features as you might 
graphics engines. Networking is more 
closely tied with players rather than the 
game's features. It's what allows your 
players to play against each other, and 
unlike the game, your players aren't such 
a known or predictable quantity 

— Crosbie Fitch 

SELECTED PROVIDERS: 

TERAZONA 

See page 12 for contact details 

BUnERFLY.NET 

See page 12 for contact details 

OPEN SKIES 
Cybernet Systems 
Ann Arbor Mich. 
www.openskies.net 

VAST 
Rebel Arts 
Calabasas, Calif. 
info@rebelarts.com 
www.rebelarts.com 

TERRAPLAY 
Terraplay AB 
Solna, Sweden 
+46 (8) 764 91 00 
www.terra play com 



DEX 

Horizon, a Glimpse of Tomorrow 
Monrovia, Calif. 
(626) 446-8925 
www.horizongot.com 

NETZANDETERNA 
Quazal 

Montreal. Quebec, Canada 
(514) 395-4646 
www.quazal.com 

SIMINTERNET 
MAK Technologies 
Cambridge, Mass. 
(617) 876-8085 
www.mak.com 

LITHTECH DISCOVERY SYSTEM 
Lithtech 

Kirkland, Wash. 
(425) 739-1659 
www.lithtech.com 

TURBINE ENGINE 

Turbine Entertainment Software 

Westwood, Mass. 

(781)407-4000 

www.turbinegames.com 

NEL 

Nevrax 

London, U.K. 

business@nevrax.com 

www.nevrax.com 

TWISTED 

Twisted Matrix Labs 
www.twistedmatrix.com 



that you define all the state variables that 
are needed (also in the database), and it 
persists the player's data in the clear 
when it can. Terazona saves out the play- 
er data as a block into the database. This 
saves you from having to define a table, 
but it also prevents you from performing 
any simple queries on the player data. 

Games that work with these assumptions. 
While both systems claim to be very 
extensible, in fact both vendors are open 
to deals that include the source. It 
should then be possible to shoehorn 
something unique into either of these 
frameworks, though this could offset the 
original reason for using one of these 
middleware solutions in the first place. 

Most of the last generation of massive- 
ly multiplayer RPGs would have been 
able to use either of these systems. Their 
landscapes are stable, the population den- 
sity of various areas is easily predicted, 
and the NPC load isn't outrageous. Both 
systems allow the tuning of the perform- 
ances characteristics to allow for a faster, 
twitch style of game. 

However, many of the coming genera- 
tion of MMOGs are starting to break the 
old mold. The Sims Online and Tabula 
Rasa both will have a very dynamic sys- 
tem of landscapes and server processes 
coming in and out of existence. Also, if 
someone decides to try a game with a 
random landscape system or an often 
modified and persisted landscape, they 
might have difficulty. 

The Details 

Terazona. Terazona server compo- 
nents are implemented almost entire- 
ly in Java. A lot of components make up 
the server suite, including the authentica- 
tion server; these include the administra- 
tion component; the NPC servers; the 
GSS, (or Game State Servers); and others. 
Inter component communication is real- 
ized by an implementation of the Java 
Message-oriented middleware standard 
provided by ICE Technology. 

The Game State Servers require the 
developer to implement a set of functions 
(their GSAPI, Game State API) in C/C++ 
and compile them into a DLL or shared 
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^ ^ ^ ^ ^ excellent 

^ ^ ^ ^ very good 

^ ^ ^ average 

^ ^ disappointing 

^ don't bother 



object that the server will load and use 
for game-state validation. The interface to 
the GSAPI proved clumsy; they give you a 
header file full of C function definitions 
and tell you to implement them. This is 
O.K., but it would be preferable to 
export a structure of function pointers, or 
implement a class with pure virtual mem- 
bers and export a factory. 

In Terazona, sections are called regions, 
but they operate much like we described 
the Game State servers. One interesting 
thing to note is the fail-over support 
inherent to their design. Since entities 
(players or NPCs, generally) are ghosted 
to the necessary neighbor regions, when a 
region server fails, another server will 
reinstantiate the region and attempt to get 
entity state from servers that had it ghost- 
ed. If that fails, it will go back to the 
database. GSS servers can be brought up 
and down while the game is running, 
without restarting other components. 
Terazona does not have its own imple- 
mentation of a landscape and does not do 
landscape validation for you. 

Terazona uses the "NPC server as a 
trusted client" model. The downside of 
this model is that sometimes the most 
complicated logic exists in the NPC 
servers, and their scalability is left up to 



TERAZONA 



O STATS 
ZONA 

Mountain View. Calif. 
(650) 964-1133 
www.zona.net 
PRICE 

Depends on project and studio size. 

O PROS 

1. Portability. 

2. Automated game state. 

3. Flexible environment model (space, 
water ground). 

O CONS 

1 . Persistent data is stored in blob format. 

2. Reliable UDP still in development. 

3. Regions are statically defined. 



the developer. The client-server protocol 
provided is based on TCP, which may be 
unacceptable for many applications, 
though Zona has promised a reliable UDP 
implementation. Because they only ask a 
small up-front fee in exchange for part of 
the subscription revenue. Zona's business 
model is attractive to new MMOG devel- 
opers. This has the extra benefit of 
increasing the support and library impro- 
vements developers will receive. 

Butterfly.net. Butterfly.net is more of a 
total solution than Terazona, which is 
not necessarily a good thing. In fact they 
are proponents of a utility model that 
allows you to use their server clusters. As 
traffic goes up and down, those servers 
are shared with other products that are 
also using the utility model. Although 
very cost efficient, this prospect could be 
frightening to even the most experienced 
MMOG live teams. They don't prevent 
you from putting the parts together your- 
self on your own systems. 

The rules management system that the 
server uses to validate game state uses 
functions written in Python. This could 
greatly simplify game authoring and also 
helps with thread safety. The Python 
interpreter is built into the game server, 
so performance shouldn't be a problem. 

The Butterfly.net system can have a 
separate NPC server for every landscape 
section (which they call locales). If you 
have an NPC-heavy game, this should 
help with the distribution of CPU load. 
(The NPC server is not written in 
Python.) However, human intervention is 
required should these NPC servers or 
locale servers crash. Butterfly.net has no 
automated server management that can 
restart processes or bring up another 
from a pool of servers. 

The suggested operating system is 
Linux with a DB2, Oracle, or Postgres 
database, but if you were required to use 
a different operating system or database, 
Butterfly.net claims that much of the sys- 
tem can be ported. Tools for porting ter- 
rain models from Maya or 3DS Max 
into Butterfly. net's Landscape quad-tree 
are also provided. 

What would we prefer? Although total 
solutions have their place, MMOGs 



might be too young of a genre to support 
this strategy. A more open-ended toolbox 
approach is proving useful for graphics 
engines such as Criterion's Renderware, a 
useful model to emulate on the server- 
side as well. This would mean a large 
collection of smaller functional libraries, 
separated by a well-documented API. 
Libraries of functions for messaging, per- 
sistence, cluster control, and terrain 
quad-trees could be combined into what- 
ever system a developer might need. 

In addition, neither system supports 
the concept of an automated generic pool 
of servers. This would entail every server 
being able to perform any function and 
would create a high amount of reliability 
with very little human intervention. 

Last word. It's very exciting that the 
massively multiplayer market is growing 
enough to support the creation of these 
types of solutions. MMOGs are fast 
becoming too complex and risky to 
develop for very much innovation to 
occur, and we are all happier if systems 
like Terazona and Butterfly.net help alle- 
viate that. Still, neither has a well- 
known MMOG that has used their tech- 
nology yet. Even so, both are strong 
contenders in this young market. '0' 

Visit www.gamasutra.com for a longer 
version of this review. 
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O STATS 

BUnERFLY.NET 
Martinsburg, W. V. 
(304) 260-9520 
www.butterfly.net 
PRICE 

Depends on project and studio size. 

O PROS 

1. Utility model. 

2. Almost a complete solution. 

3. Persistent data is stored in the clear 

O CONS 

1. Utility model. 

2. Lack of automated disaster recovery. 

3. Locales are statically defined. 
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Matt Toschlog's 

Descent into Outrage 




Outrage's Matt Toschlog 



Since 1986, Matt Toschlog has 
enjoyed a varied Hfe within the 
game development industry. 
Starting his journey at 
Sublogic, Matt continued 
through Looking Glass Technologies, to 
Parallax Software (which he co-founded), 
and is now Studio Director for Outrage 
Games, a company he splintered off from 
Parallax and was president of until its recent 
acquisition by THQ. One of his most 
notable contributions to videogame history 
so far includes the Descent series. 

With what looks to be an ongoing trend 
of big publishers and media conglomerates 
acquiring once-independent developers, we asked Matt — 
among other things — to give us an insight on what things are 
like after the Big Change. 

Game Developer. Do you think the current trend of third-party 
developers being acquired by publishers bodes well or badly for 
the industry? 

Matt Toschlog. It's a good thing in that it allows third-party 
developers to keep making games. As games and team sizes and 
budgets have grown, it's become increasingly hard for inde- 
pendent developers to survive. The stakes are too high, and 
publishers are hesitant to spend the money required to make a 
great game if they don't have more control over the process. 

GD. How do you see your work changing from the days of Parallax 
to the present? Has working for THQ changed your work behavior in 
any way? 

MT. The biggest change is that I don't program anymore. 
When we wrote Descent I was one of three principal program- 
mers. Now I'm a full-time manager. Another major change is 
that our projects are much bigger. At the end of Descent we 
had eight people working on the game; our current project. 
Alter Echo, now has about 25. That means a lot more manage- 
ment and coordination, and a much less intimate environment. 

At the time we were acquired, we'd been working on Alter 
Echo for THQ for about a year. When our other publisher ran 
into trouble, it was natural for THQ to step in. We were in the 
middle of our E3 crunch when the acquisition happened, and 
we just kept on working. We had to shift some people around 
when our other project was cancelled, but for most people. 
Outrage isn't much different now than before THQ came in. 

GD. Do you think the creative process of making a game is 
affected by these acquisitions? Is there more paperwork, strategy, 
and playability planning going into the making of a game in a big 
company than in smaller ones, where things can be a lot more flex- 



ible as the game design and programming unfolds? 

MT. I think the creative process is affected by 
the size of the games. If a company is going to 
spend 5 or 10 or 20 million dollars on a game, 
they're going to want to keep close tabs on where 
the money is going. You've got to be a lot more 
careful when you're spending that kind of money. 

GD. What role do you see middleware playing in 
the future of game development? 

MT. Middleware is starting to be a real factor. 
These days, most consumers don't care as much 
about technology. Developers realize that and 
want to focus on content; using stable develop- 
ment systems make that easier. We've always 
written out own engines here, and will probably 
continue to do so, but we're placing a high premium on writing 
reusable code. 

GD. you served as chairman for the International Game 
Developer's Association (IGDA) for a couple of years. How do you 
see the organization's goals compared to when you came on board? 

MT. I think the goals of the IGDA have remained pretty con- 
stant — to be the voice of the professional developer and to 
provide support to the people making games. What's changed 
— steadily, though sometimes slowly — is our ability to fulfill 
those roles. We've been building membership, establishing pro- 
grams, making contacts, and generally creating a foundation. 
Many of us who have been with the IGDA for the last few 
years got involved because we had a vision of where the associ- 
ation could be down the road. We're still looking toward the 
future, but we've already come a long way. 

GD. Do you miss those garage days when you first started creat- 
ing Descent? Do you ever wish for a return to those simpler days? 

MT. Oh, yeah. It was great being hungry and lean like that. 
Sometimes we talk about doing a GBA game to try and re-cre- 
ate that atmosphere. 

GD. Looking back, what elements made the Descent series the 
success that it was? Do you think those elements came together by 
choice or chance? 

MT. Descent offered the classic game mechanic of "shoot all 
the bad guys" in a way that no one had seen before. At the time, 
3D games were still somewhat new, and Descent was the most 
3D of them all. Piloting a ship through those crazy tunnels pro- 
vided a challenge that rewarded those who could master it. 

I think success depends a lot of chance. One thing I've learned 
is that no matter how hard you work and how well you plan, 
there's still a huge amount of luck that determines whether your 
game is fun or if the customers will care. If we really understood 
how to make hit games, then every game would be a hit. '0' 
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Clustering 



For the past two months I've been discussing profil- 
ing. I started out by decrying the lack of good pro- 
filing tools for games; I talked about the difference 
between a "batch profiler," like VTune or the 
Code Warrior profiler, and an "interactive profiler," 
Hke the ones we usually build into our games; I then proceeded 
to make a big wish list of features that a good interactive pro- 
filer might provide. 

Chief among those features was the ability to abstract the pro- 
gram's timing measurements into higher-level "behaviors" and to 
do some analysis regarding the frequency and consistency of 
these behaviors. Modern games don't exhibit one consistent pat- 
tern of resource usage. At one time they might be fill-rate limited 
by the graphics card, at another they'll be slowed down by an 
abundance of pathfinding and physics. A tool that helps us visu- 
alize these patterns would be valuable. 

Finding a Clustering Method 

Let's look at Table 1, which I introduced in last month's col- 
umn ("Interactive Profiling, Part 2: Behavior Analysis," 
January 2003). Here we see three behaviors: behavior A is ren- 
dering-heavy, B is physics-heavy, and C is Al-heavy. Imagine the 
numbers in the table came from a profiling run of a game in 
progress; as each frame is processed, we get a new set of timing 
numbers. Now suppose that the next frame is measured, produc- 
ing the results: rendering 72%, physics.sim 17%, ai.pathfind 11%. 
Those numbers are very much like behavior A. Even though the 
numbers do not match exactly, we would expect the profiling 
tool to classify this frame as exhibiting behavior A. 

That's not hard to implement when you have a predefined 
list of behaviors like Table 1. It's harder when you start from 
scratch with no preconceived notions of program behavior. In 



TABLE 1 . The CPU usage profiles for three different behaviors A, 
B, and C, measuring time spent in three different program sections: 
"rendering," "physics.sim," and "ai.pathfind." 



Behavior: 


A 


B 


C 


rendering 


75% 


25% 


25% 


physics.sim 


15% 


65% 


15% 


ai.pathfind 


10% 


10% 


60% 



general, we are faced with a clustering problem: given a bunch 
of vectors containing timing data, we want to arrange the vec- 
tors into groups, where the centroid of each group can be used 
as a summary. 

Clustering is a common task in computer science and engineer- 
ing applications, and many algorithms have been developed, for 
example so-called ^-means clustering. Here's how ^-means 
works: First, randomly partition your input into a set of initial 
clusters. Find the centroid of each cluster. These clusters obvious- 
ly won't be perfect yet, so to fix that problem, you iterate over 
each input vector and reassign it to the cluster whose centroid is 
nearest. Now recompute the centroids. Repeat this reassignment 
process until the results converge, and you perform an entire pass 
without changing anything. 

The name "^-means" indicates that there are some number of 
clusters (k of them), and that we are representing each cluster by 
its center (by the mean of the input values). 

Unfortunately, ^-means and most other clustering methods are 
batch algorithms. They require you to have all the vectors avail- 
able at once and to access those vectors randomly. Since I want 
an interactive profiler, which can classify behaviors on the fly 
during a single program run, these algorithms are unsuitable. 

Nonbatch Clustering 

There's a special term for clustering algorithms that can handle 
streaming input: they are called "online clustering algo- 
rithms" For example, there's an "online ^-means." 

Online ^-means works like this: Start with k cluster centers 
arbitrarily distributed through space. For each input vector you 
want to classify, find the closest cluster point, classify the vector 
into that cluster, and move the cluster point closer to that vector. 
(See "Radial Basis Function Learning" in For More Information.) 
Online ^-means really is an incremental version of batch k- 
means, but making the algorithm incremental is a big change, so 
the explanations of the two versions sound fairly different. 

How do you decide how many clusters are necessary to repre- 
sent your data stream accurately? There are some heuristics that 
involve removing cluster points when you have too many (some 
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of them are lying idle, never attracting input) and adding cluster 
points when you have too few (when the radius of space attrib- 
uted to a particular cluster point is too large). Unfortunately, 
these heuristics all require some kind of a priori knowledge of the 
data: you need to know how many samples is the minimum for 
considering a point to represent a valid cluster, or how spatially 
large a good cluster is likely to be. In other words, you need a 
good guess about the duration and scale of your data. 

But we don't want to have to guess at that stuff in order to get 
a good profile. Really, we want the computer to figure out 
appropriate values from context. And those values may need to 
change. If we are running our game for five minutes and see 
some frames that spend 70 percent rendering, 75 percent render- 
ing, or 80 percent rendering, we probably want to draw distinc- 
tions between these and call them three different behaviors. But 
then if we walk into another room in the game and we start see- 
ing a lot of behaviors like B and C from Table 1, then perhaps all 
of the previous frames should be categorized as A. 

Clearly, some kind of hierarchical clustering is necessary. It's 
probably best to let the user decide at which detail level to view 
the abstractions; we should maintain a tree of behaviors from 
which the user selects a particular view. Unfortunately, the typical 
methods, such as hierarchical agglomerative clustering, tend to be 
data-intensive batch processes. 

Visualization 

There's one other problem we need to solve for effective visu- 
alization of our profiling data. In a full-sized game, there 
may be a few hundred different subareas of the program for 
which we get profiling data. In clustering terms, we're clustering 
data points that have a few hundred dimensions each. Suppose 
we manage to do this, and we get a result with 15 different 
behavior clusters. Those clusters are still points in a high-dimen- 
sional space. We can list them, like in Table 1, but we'd like bet- 
ter methods of visualization. Maybe we want to project these 
clusters somehow onto a 2D chart and have the clusters that are 
most alike placed near each other on that chart. Maybe the two 
dimensions of the chart can even mean something, related to the 
two biggest ways in which the behaviors tend to vary. 

There are some well-known methods for projecting multidi- 
mensional data onto a 2-plane. These methods tend to fall into 
two categories: ad hoc, producing poor results; and complicated, 
slow, and scary. There's another alternative, though: a hybrid 
kind of algorithm that clusters and projects simultaneously, and 
does a good job of both. 

The Self-Organizing Map 

In this month's sample code, I used this hybrid algorithm, the 
Kohonen self-organizing map (SOM) to perform the classifica- 
tion of CPU behavior. The SOM is an array of points in the input 
space; all the points are initialized to random values. For each 
incoming frame of profiling data, we find the closest point in the 



SOM. We then move that closest-match point toward the posi- 
tion represented by the incoming frame, just like online ^-means. 
But the SOM does something extra: in addition to giving the 
clusters positions in the input space, it treats them as having posi- 
tions in another space also. The clusters have fixed positions 
along a regular grid, in what I will call "neighbor space." When- 
ever you move a cluster center toward an input in input space, 
you also look up its neighbors in neighbor space and move those 
neighbors through input space in the same direction, thought not 
by as much. 

This neighbor space is usually implemented just by storing the 
cluster data in a 2D array and by iterating across nearby cells in 
that array. You can think of this as applying a "move filter" to 
the array, where the filter kernel is high in the center but tapers 
off with an increasing radius. 

After many such iterations, the clusters in input space will con- 
verge, just like ^-means. The size of the move filter shrinks over 
time as the clusters become settled, until it becomes a point. The 
"self-organizing" part of SOM represents the idea that, because 
we applied that move filter in neighborhood space, we were con- 
stantly influencing neighboring array cells to take on similar val- 
ues. So after we are done processing our inputs, we not only get 
cluster centers, but the clusters are arranged in the 2D grid 
according to similarity. We can generate a 2D display where simi- 
lar clusters are drawn near each other, which can help us under- 
stand the data. 

This is a quick-and-dirty description of the SOM, with some 
simplifications. For reasons of isotropy, like we saw when look- 
ing at networking ("Transmitting Vectors," July 2002), it's usual- 
ly better to use a hexagonal tiling than a rectangular grid. Also, 
the SOM grid can consist of any number of dimensions, but two 
dimensions is the most common choice, since a map with more 
dimensions is harder to visualize. Finally, initialization of the 
SOM is best done using some attributes of the training data, 
since a random spread in a high-dimensional space is likely to 
produce points that are not near anything in your data set. In this 
case, the only way array elements are used is when they get 
dragged into use by a neighbor, so it takes a while before the 
SOM is working at reasonable effectiveness. 

For some references that explain self-organizing maps in 
greater detail, see For More Information. 

Adapting the SOM to Real-Time 
Tasks 

The SOM is a batch algorithm for two reasons. For one, to 
produce good results, the algorithm wants a randomly 
ordered sampling of the data. Imagine first presenting all your 
samples of behavior A, then presenting an equal number of sam- 
ples of behavior B, which happens to land in a cluster neighbor- 
ing A, so the movement filter for B wipes out most of A — this 
process will not produce desirable results. 

The second reason the SOM is a batch algorithm is that it 
wants to have a global notion of time. Early in training, the 
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movement filter is very large; over time it shrinks, until toward 
the end of training it's almost a point. But with live input data, 
we don't know how long we will be running, and we may wish 
to run indefinitely. So I made some modifications to the SOM 
algorithm to adapt it for real-time data. These modifications are 
somewhat questionable, since I have not analyzed them deeply, 
and I can already think of some ways they may be problematic. 
But to a first approximation they work O.K. 



Shrinking the Filter 



Rather than using a global time, I introduced the idea of 
"local convergence," which is a value between and 1. The 
filter size centered around any given array cell depends on that 
cell's local convergence: a convergence of means a big filter, 1 
means a small filter. 

Whenever a point in the SOM is generally staying in the same 
place, its convergence value increases. If it starts getting yanked 
someplace else, its convergence value decreases. I use the IIR fil- 
ters I described in "Toward Better Scripting, Part 1" (October 
2002) to track the trend of a point's motion. If many training 
steps confirm the positions of some region of the map, that 
region will no longer feel the need to upset its neighbors. But if 
an area of the map keeps being upset, its "local time" will go 
backward and it will jostle its neighbors in a bid to create more 
space for the competing values. 

This "hardening of the map" does to some extent alleviate the 
"B wipes out A" problem but does not solve it. To solve it, I 
would implement a hierarchical series of maps, with maps that 
change quickly, feeding data into maps that change more slowly. 
I haven't had time to try this yet, but I plan to soon. 

One further problem is that there's no way for the SOM to 
grow. To achieve reasonable results, you need to construct it with 
enough initial nodes. But I believe hierarchical maps would solve 
this problem as well. 

Initialization 

■ wanted a good way to initialize the SOM. As I mentioned ear- 
lier, random initialization is not so good. The way it's usually 
done for batch data is to perform principal component analysis 
on all the input, find the two non-axis-aligned dimensions along 
which it has the greatest spread, and initialize the SOM array 
entries to cover that spread evenly. In other words, you find the 
covariance of the data with respect to the mean, then pick the 
two longest axes of the multidimensional ellipsoid. This process 
is just an fz-dimensional version of what I demonstrated in "My 
Friend, The Covariance Body" (September 2002). 

Since I don't want to wait for the whole batch of input data, I 
collect 10 frames' worth of "warm-up points" before the SOM 
kicks into training mode. Then, because I didn't want to write n- 
dimensional matrix decomposition code, I approximate the 
spread as follows: First I pick a random warm-up point, then I 
find the warm-up point that is furthest from it. I find the vector 



between them, and that is the longest axis of the spread. Then I 
remove that dimension from the warm-up data by subtracting 
each point's projection along that axis. Then I choose another 
random point, find the warm-up point furthest from that one, 
and that is the second-longest axis of the spread. I then initialize 
the SOM entries to points evenly spaced across the plane defined 
by these two axes, centered on the mean. If the axes are degener- 
ate within some numerical threshold, then I seed the SOM with 
random offsets from the mean. 

Sample Code 

This month's sample code (available at www.gdmag.com) is an 
updated version of the toy game world that I described in my 
December column ("Interactive Profiling, Part 1"). In addition to 
Al-heavy and entity-render-heavy behavior modes, there's now a 
sun in the sky. When you look toward the sun, ridiculous 
amounts of lens flare are drawn, bogging the system down. 

As you move around the game world, you'll cause various 
behaviors that are mixtures of AI, entity, and lens flare. 
Whenever mouselook is enabled so that you can move around, 
the game system takes each frame's profiling data and classifies 
it using an SOM. When mouselook is disabled and the SOM is 
paused, you can move the mouse pointer over the SOM's dis- 
play and look at the behaviors it has detected. 

There are a number of visualizations enabled, which are 
explained in the README. These visualizations aren't as intu- 
itive as I'd like, but after a bit of exposure you get used to them 
and can infer interesting relationships about the clusters by look- 
ing at colored diagrams. 

Future Work 

So far this work has been pretty experimental, but I think it 
shows some promise. I am going to try some hierarchical 
versions of the SOM and online ^-means and will report on 
their effectiveness in a future column. In the meantime, next 
month I'll go back to a more conventional topic: creating bet- 
ter-looking graphics. ^ 



FOR MORE INFORMATION 



Kohonen, Teuvo. "The Self-Organizing Map (SOM)" 

•xAv.cis. hut.fi/projects/somtoolbox/theory/somalgorithm, s 

Moore, Andrew W. "K-Means and Hierarchical Clustering" 
www. cs . emu . edu/~ awm/tutorials/kmeans09 . pdf 

Palmeri, Paolo. "Radial Basis Function Learning" 

http://miles.cnuce.cnrit/~palmeri/datam/articles/okmc.ps.gz 

Vesanto, Juha, Johan Kimberg, and others. "Enhancing SOM-based Data 
Visualization" • cis.hut.fi/projects/ide/publications/html/iizuk' 



20 



february 2003 I game developer 



|[Return 



ARTIST S VIEW 



a y d e n d u v a 1 1 



What's Wrong with 
Our Games? part 2 




I have heard 
many 
times, 
expressed 
in a variety 
of ways, that the 
success of a 
game Hes firmly 
v^ith its execu- 
tion rather than 
in its design. It is 
a fact that many 
ideas and their 
initial design 
documents put 
forward what 
seems to be an 
interesting and exciting 
concept, but by the time 
the game finds itself on the shelf, it 
has turned into nothing more than a 
mediocre space-filler that will find a home 
in the bargain bins within the month. 

I'm sure that any experienced devel- 
oper reading my column could write me 
a list as long as my arm of the reasons 
why a finished game differs substantial- 
ly from the original design spec and 
, why, in general terms, evolution of ideas 
through the development process is 
always a good thing. Implementation, 
rather than initial ideas, usually 
^ accounts for the eventual quality of a 
game when it is released. 

There is no area more relevant to the 
discussion of implementation than that 
of a game's visuals. The irrelevant lan- 
guage of a pitch document that promis- 
es a game "set in richly detailed fantasy 
world of epic proportions" has to trans- 



character cre- 
ation, this month 
I'll look at some 
additional areas 
in game visuals 
that often lose 
something in the 
translation from 
page to screen. 

Lighting 



late meaningfully onto the 
screen to have any chance of being even 
close to the truth. If you run such a doc- 
ument through a truth filter, many such 
sentences would read, "Set in a routine- 
ly realized fantasy cliche, made to 
appear large by repeating the same 
geometry over 100 times." 

Continuing the theme I began in last 
month's column ("What's Wrong with 
Our Games? Part 1," January 2003), in 
which I covered design, animation, and 



ne indication of 
how videogame 
technology is improving is the quality 
of the lighting available to designers. 
Unfortunately, many games still view 
lighting as number 138 on their list of 
things to pay close attention to, and as a 
result, the energy developers spend creat- 
ing a world of detail and quality is wast- 
ed for many games. They pay little atten- 
tion to lighting, or decide not to invest 
much time in their light-related technolo- 
gy. Nasty lighting can hammer even a 
well-constructed scene to death, whereas 
high-quality lighting will bring a scene to 
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life. Attempting to re-create the real- 
world behavior of light in a 3D scene has 
led to a whole variety of lighting solu- 
tions over the years. 

Initially, severe color-palette restric- 
tions made the idea of lighting irrele- 
vant, but as we moved through the 8-bit 
and then the 16-bit era, the simulation 
of lighting effects allowed our early 3D 
worlds to appear more solid. Once true 
3D began to appear, it wasn't long 
before basic light sourcing was a com- 
mon feature. Today, artists 
can apply just about any 
high-end lighting solution 
to some degree in a gaming 
context, and the question 
of which solution to use 
then depends on cost ver- 
sus benefit and which plat- 
form you're dealing with. 

Up until recently, the 
most advanced of these 
solutions have been excep- 
tionally slow. Unless you 
had access to a render farm 
the size of Alaska, the mas- 
sive amount of numbers being crunched 
manifested themselves in single-frame 
render times that were measured in 
weeks rather than minutes. 

Artists now have the tools and the tech- 
nology to do more than place colored 
point lights around a scene that they hope 
will do the job. The approximation of real 
light distribution is now more accessible 
within the limitations of a game world. 
Designers can now use texture baking to 
incorporate the subtleties of radiosity, 
global illumination, and lighting from 
high-dynamic-range images. 

Texture baking has been around for a 
while, but the newest iteration of many 
high-end renderers now brings together 
the most advanced lighting solutions 
with the ability to render this light 
information to textures. Whether the 
light information is rendered into a sep- 
arate layer to be added on top of more 
traditional texturing or added directly 
to the textures themselves, the results 
one can achieve are far more realistic. 



The downside is that texture baking 
can destroy texture memory in no time 
flat. The price to pay for what is effec- 
tively light distribution information, 
customized for each surface, is that the 
cost to memory can be massive in scenes 
with a huge amount of surfaces. Con- 
densing multiple light maps into more 
economic single textures, applying low- 
resolution light maps on top of regular 
texturing, and careful level design that 
takes these limitations into account can 



all make texture baking more usable. 
While the cost is high, the quality of the 
end result can be worth it. 

Textures 

The easiest targets for game artists to 
pick on when examining the work of 
their peers are most probably the textures 
and the texturing. Many games now have 
extremely large worlds that can be 
explored in fairly close detail, and as a 
result, it is hard to find a game that has 
faultless texture work across its entirety. 

That said, there are a few texture prob- 
lems that appear time and again in games: 

Bad mapping. Bad mapping can take 
many forms, some worse than others, 
and usually indicates either a lack of time 
and resources, or some level of apathy on 
the part of the offending artist. 

Faced with a significantly large 
amount of geometry to texture in a given 
time, it is understandable that inconsis- 
tencies should appear. Texture streaking 



from applying a planar map across faces 
that are nearly perpendicular to the UV 
plane is one example of careless or hur- 
ried mapping that looks very ugly. 

Seams that show painfully obvious 
joins between mapped sections can also 
stand out, especially if the geometry is 
large, like a rock face for example. With 
many complex objects, especially organ- 
ic shapes, it's all but impossible to map 
the entire surface with a continuous, 
seam-free texture, so some jiggery-pok- 
ery is often needed to reduce 
the appearance of problems. 

Many designers overlook the 
option of placing joins in the 
texturing where they will be 
the least visible. This may seem 
like an obvious solution, but 
it's important to remember 
that "the least visible" means 
from the player's perspective, 
not that of the artist, so devel- 
opers must play through the 
sections in question carefully to 
assess the least visible areas for 
these scenes. 
Another crude but nonetheless worth- 
while problem-masking technique is 
using textures that naturally minimize 
the appearance of seams. Such textures 
are those that are even in terms of 
detail, color, and contrast. Ideally, a sys- 
tem that obscures unavoidable seams, 
such as multitexturing, works better, as 
long as the artist has the time and the 
inclination to take advantage of this 
method. 

Specular and bump mapping. Specular 
and bump mapping technologies are not 
new, but they are only now becoming 
practical in any real sense for main- 
stream gaming. Still, heavy-handed 
application of just about anything, 
regardless of how nice it is, can ulti- 
mately do more harm than good. Both 
bump mapping and specular effects have 
the ability to introduce additional and 
dynamically responsive material proper- 
ties to surfaces within your game. But if 
they are applied with no concept of 
restraint, they will end up being intru- 
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can ultimately do more 
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sive gimmicks that turn a game's visuals 
into an unsuccessful mess. 

Coupled with dynamic light and shad- 
owing, bump mapping is a particularly 
useful way to achieve the appearance of 
fine surface details without using actual 
geometry. But many designers are drawn 
into making just about everything bumpy, 
or at least into adding bumps where they 
have no real need to be. Likewise, specu- 
lar maps can seduce artists into finding 
ways to incorporate specular effects on 
every object they create, not a good idea 
in most circumstances. 

Bottom line: Restraint is key, as the 
player's attention is drawn to the areas 
where the techniques I've just mentioned 
are used judiciously, rather than to excess. 

Straight from scan. Any game that is 
attempting a certain level of realism is 
likely to use photographic sources in its 
texture generation. Problems arise when 
the initial scan or digital photo finds its 
way into the game without any signifi- 
cant processing. The end result of 
unprocessed images is usually textures 
that feel out of place or flat. As most tex- 
tures need to be balanced for brightness, 
contrast, and other properties to make 
them consistent with the game world, 
neglecting to process images will usually 
make them stand out unnecessarily. 

Scaling gone wrong. Another common 
problem arises when textures are com- 
pletely out of proportion with the envi- 
ronment that they are supposed to be 
part of. This problem is especially com- 
mon in larger areas, where a texture is 
likely to be repeated many times, and 
artists sometimes cut down the number 
of repeats by scaling a texture up. 

The problem becomes most apparent 
when a character (or player, if it's third- 
person) is in close proximity to the 
offending texture, where it is possible to 
see that the heads of the nails in the 
wooden planks are actually the size of 
watermelons. This kind of scaling mis- 
match is easy enough to avoid, but it 
requires the artist concerned to pay 
close attention once again to the player's 
experience, as opposed to building and 



texturing geometry in isolation. 

Environment mapping. The use of an 

environment map, particularly in con- 
junction with other layers of texturing 
in order to give the appearance that a 
surface is reflective, has become one of 
the most abused effects of recent times. 
It is a toy that needs to be put back into 
its box and only brought out when it 
genuinely fits. 

Especially bad offenders combine 
environment maps with such effects as 
worn and damaged metal surfaces, so 
that a material that should be relatively 
unreflective ends up looking like it has 
been coated with a very thick layer of 
varnish and buffed to a mirrorlike shine. 
Here again, restraint is key. 

Cutscenes 

The art of creating the perfect cutscene 
is a large enough topic to warrant sev- 
eral columns, but when asking others 
what they think most often goes wrong 
with cutscenes in a game, the almost uni- 
versal answer is that they are too long. 

The debate about what the role of the 
cutscene actually should be in a game has 
several contrasting viewpoints. Still, no 
matter how cutscenes are presented, 
whether in-engine, 100 percent preren- 
dered, partially interactive, or whatever, 
the bottom line should always be: do 
they improve the player's experience, or 
do they just get in the way of enjoying 
the game? 

This can be a difficult question to 
answer, as my idea of a great cutscene 
could be the opposite of what you are 
looking for. However, because lots of peo- 
ple feel that long cutscenes intrude on the 
experience of playing a game, it would be 
a good idea to look at ways of reducing 
cutscene length where possible without 
compromising story or atmosphere. There 
is a limit to how much information a 
player can retain from a cutscene, so if it 
does contain things they need to remem- 
ber, then dragging it on will make that 
more difficult. 



Geometry 

Now that polygon counts are less of 
an issue than they were a few years 
ago, such problems as having to use five- 
sided cylinders or being forced to resort to 
triangular cross-sections everywhere don't 
exert the pressure they once did. Building 
environments that look good isn't sudden- 
ly a piece of cake just because we can be a 
little freer with the triangles, but the prob- 
lems at present tend to focus more on 
such elements as texturing, lighting, or 
general design issues. 

In this respect, it isn't the quality of the 
geometry that is a problem; it often has 
more to do with the variety of geometry 
used, particularly when it comes to interi- 
or spaces. It's very easy to decide that the 
corridors of a space station would, in real- 
ity, all be pretty much identical, so why 
not just take a section of geometry that 
you are happy with and duplicate it as 
many times as necessary? Likewise, the 
sewers under the castle are all made from 
the same brick, so why build 10 variations 
of the same thing? 

Repetition is a great time saver, and 
when you use it with care it can be vir- 
tually invisible to the player. On the 
other hand, without enough unique 
geometry or some other form of land 
marking, a player can get lost quite easi- 
ly. Navigating an area may seem simple 
to the artist who created it, but often 
the modeler's perspective is completely 
different from the player's restricted 
viewpoint. For the player, figuring out 
how an area is laid out, even somewhere 
that is relatively uncomplicated, may 
prove to be quite a task. 

Aside from the possibility of becom- 
ing disoriented, a player can also bore 
quickly if the visuals become overly 
monotonous. The artist has failed in his 
or her task if players switch off because 
they are tired of wandering around loca- 
tions that all seem to be essentially the 
same thing. 

In the end, we can't expect our games 
to be 100 percent perfect in every 
respect. But in the quest for greatness. 
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SOUND PRINCIPLES 



Simon amarasingham 



Music That Won't Give /ou a Rash: 
Taking the irritation out of 



Repetition 




o matter how much you 
love your favorite piece of 
music, if you hsten to it 
enough times, the repeti- 
tion becomes annoying. 
In-game music is subject to this kind of 
repetition, so how do you avoid irritat- 
ing hsteners? Given that repeating ele- 
ments is a fundamental part of composi- 
tion, let's look at how the game's audio 
engine affects the fundamentals. 

Repetition in the structure. Music is 
typically structured in patterns. For 
example: 
A-B-A-B-C-B 

denotes a typical rock-song structure, 
where A is the verse, B is the chorus, 
and C is the bridge. Notice that B actu- 
ally takes up half the piece — this is 
done purposefully so by the end of the 
piece the listener should be able to hum 
the chorus. 

Even though the point is to hammer 
home the chorus, there's a reason the 
song doesn't simply feature the chorus 
all the way through. The contrast of 
other musical sections is required the to 
avoid boring the listener. Although there 
are examples of 20th century music that 
push the envelope in the realms of con- 
trast and repetition, for the most part a 
good balance is required. 

But what happens to this balance 
when a game's audio engine loops a 
piece of music? Our example structure 
would end up looking like this: 

A-B-A-B-C-B — A-B-A-B-C-B — A-B- 
A-B-C-B — and so on. 

In just three loops we've heard B nine 
times and we're already sick of it. 
However, we can remedy this situation 
by breaking some of the traditional 
rules of composition. 

The trick is to write with the structural 
repetition reduced to the point where the 
piece needs to be heard many times in 




order to "understand" it. An extreme 
example of such a structure might be: 
A-B-C-D-E 

A music professor would give such a 
piece an F , because in theory it would 
lack coherency. However, when the game 
engine repeats the piece over and over 
while you're killing monsters, the player 
eventually becomes familiar with all five 
parts. It would take considerably more 
repetitions than the rock-song example 
to get to know this piece, which is exact- 
ly what we want. 

For most composers, it's quite hard to 
write something completely lacking in 
repetition. They have a deeply ingrained 
instinct to use repetition, so it's better to 
try easing into it rather than giving it up 
cold turkey. If we took the rock-song 
structure, wrote an additional D section, 
and varied one of the A sections to give: 

A-B-A'-D-C-B 

we'd have a tune that is much more 
loop-friendly without being completely 
incoherent. 

Repetition in the melody. Just as the use 
of structure needs to be reconsidered in 
the context of in-game repetition, so does 
that of melody. A melody or theme is the 
most commonly remembered element of 
a piece of music. While the arrangement 



and groove may be pleasing, the melody 
is what the listener actually remembers. 
In a game, this can be bad — every time 
that theme pops up, the player notices it. 

Themes are built using a structure. 
John Williams' opening theme for Star 
Wars uses a single rhythmic motif repeat- 
ed four times with a variation on the last 
repetition. It's brilliantly crafted and high- 
ly memorable — too memorable, in fact, 
to be heard many times in succession. 

Many of the preceding suggestions 
regarding the structure of a piece of music 
can be applied to creating themes. For 
example, you could try increasing the 
variety in the motifs that make up the 
theme. However, we'd like to make the 
case for not using full themes at all in 
games. Rather than making a coherent 
musical sentence using short motifs, try 
leaving the pieces unglued, peppering your 
piece with smaller fragments instead. By 
varying these motifs so that you seldom 
hear the same one twice, you can achieve 
musical coherency without hitting the lis- 
tener over the head repeatedly with a sin- 
gle attention-grabbing melody. 

The final mix. The result of all this 
reduced repetition will be music that plays 
well over the course of playing a game but 
doesn't stand up very well to a single lis- 
ten. So if you're presenting music tracks 
independently of the game, such as on a 
CD, you may need to create different ver- 
sions of the pieces that incorporate a more 
usual level of repetition. We never prom- 
ised that better game music was going to 
be easy. ^0" 




SIMON AMARASINGHAM I Simon is a composer/sound designer 
with dSonic (www.dsonicaudio.com), a company that creates music 
and audio specifically for the game industry. Kemal Amarasingham 
and Vincent Stefanelli, who are also founding partners of dSonic, 
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its include System Shock 2, Arx Fatalis, and Masters of Orion 3. 
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Good Points Don't Go 

Down 



One of my favorite jobs as a freelance 
designer /producer is doing game/studio 
reviews for publishers. Working on a 
design on my own can be an isolating 
experience, so I relish the opportunity to 
get out in the world to visit a develop- 
ment studio and essentially do a tune-up, 
advising them on business plan, company 
or game team structure, and tools and 
techniques to manage their games to 
completion. But my favorite part of that 
experience is tinkering with the design, 
looking for ways to help them improve 
the game while minimizing production 
costs and risks. 

I've found the growing body of game 
rules very helpful in this process. I often 
switch roles from sage to scholar as some- 
one makes a suggestion about the game 
design, and I think, "Rule!" and jot it 
down. One such moment came during a 
meeting at Firetoad Software in Calgary, 
reminding me of one of the very first rules 
I learned in the arcade business. 

The Rule: Don't take away points or other 
hard-won possessions from the player. 

It's often tempting to design a 
penalty for the player to empha- 
size failure at a task or to dis- 
courage the player from attempt- 
ing to do something in the game 
you don't like. But failing and being dis- 
couraged just aren't fun. There's always 
a way to turn it around and reward the 
player for success, or encourage them to 
do what you want. 

The Rule's domain. This rule applies to 
all games but is particularly important 
where points are awarded, as in sports 
games. 

Rules that it trumps. This rule should 
trump the temptation to take things away 
from the player for reasons of realism or 
to add excitement. 

Rules that it is trumped by. Make villain 
and opponents evil to the player, not just 




The game Chase awards points for success 
rather than taking them away for failure. 



the character. There are cases where it 
can be a good thing to take things away 
from the player — a villain in a game 
who is out to destroy the world is well 
and good, but when he takes away your 
character's best magic sword, he's really 
evil! The caveat is that in defeating (or at 
least challenging) that villain it becomes 
possible to win back whatever you have 
lost. This technique has been used effec- 
tively in games as far back as the thief in 
ZORK, or the temporary loss of coins or 
rings in many platform games, or as 
recently as Baxter's transformation in 
JAK & DAXTER. 

Examples and counterexamples. Let's 
consider two frequent violations of this 
rule. First, we have racing games that 
use timers to deduct from the score 
when the player is slow to finish, some- 
times to the extent that it is impossible 
— dare I say pointless? — to try to fin- 
ish the race. Why not, as in the new 
Xbox game Chase from I-Imagine, give 
a bonus when the player finishes early? 
Or use a countdown bonus timer that 
counts more slowly with time, so there's 



always some bonus, but one that 
increases geometrically the faster the 
player finishes. Second, in some shoot- 
ing games when the player hits a team 
member or non-combatant, they turn on 
him in anger, and points are deducted. 
It's just as easy, and more fun for the 
player, to award a bonus for not hitting 
them, or even award the player with 
extra help or gifts as appropriate from 
gratefully spared civilians. 

Tidbits from the e-mailbox. Dave 
Grossman was one of many who respond- 
ed to the "Godfather Paradox" (Novem- 
ber 2002) column. He offers some rules 
that I'll paraphrase for brevity: 

• Have a realistic budget: Don't assume 
it can be done for less than the original. 

• Cut some good stuff: Make room for 
new innovation by resisting the tempta- 
tion to rehash all the good bits of the 
original. 

• Pretend it's not a sequel: Challenge 
yourself to think of it as an original 
game. 

Like a teenager moving out of the 
house, says Dave, the sequel must find 
its own path. His credentials include 
Day of the Tentacle, an excellent 
example of his rules. 

Finally, Ray Mazza, a graduate student 
at Carnegie Mellon University, suggests 
using popular musical themes from origi- 
nal games and building on them in the 
sequels, and similarly using some recog- 
nizable territory as a part of the new, larg- 
er world. That reminded me of how nicely 
Diablo II did both of those things by 
including the town of Tristam along with 
its signature musical theme. 




NOAH FALSTEIN I Noah is a 22-year veteran of the game 
industry. You can find a list of his credits and other information at 
www.theinspiracy.com. If you re an experienced game designer inter- 
ested in contributing to The 400 Project, please e-mail Noah at 
noah@theinspiracy.com (include your game design background) for 
more information about how to submit rules. 
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Giving Life to 

R ATC H £T & 

Clank 



Enabling Complex Character 
Animations by Streamlining Processes 



At first, we were thrilled. As 
character animators, we 
couldn't have asked for a 
better project. There were 
two heroes, dozens of ene- 
mies, scores of NPCs, and more than 
100 character-driven cutscenes. Enthusi- 
asm and artistic latitude made it all ours 
for the taking. 

But staying true to our shared vision of 
Ratchet & Clank meant that our digital 
actors needed to become more than mere 
cycling automatons. We regarded each 
character as an intermediary through 
which we could reach out to players and 
draw them deeper into our universe. This 
meant our characters needed to blend 
physically into their environments, emo- 
tionally into their situations, and expres- 
sively into our narrative. It was on these 
principles that we based both our objec- 
tives and our standard of success. 

Our team acknowledged that a rift 
existed between the level of complexity 
we desired and the time we had sched- 
uled to implement it. In order to sur- 
mount this obstacle, we developed sever- 
al methods for using Maya, our artistic 
skills, and our time more effectively. 

This article will discuss these methods 
both in terms of their functionality and 
their implementation. To this end, it will 
provide technical details on our testing 
practices, our MEL shortcuts, and our 
real-time animation procedures. 
Furthermore, it will explain how each of 
these methods saved us valuable produc- 
tion time, enabling us to achieve our 
artistic goals. 



Testing with Prototypes: 
Why and How 

Part of achieving our goal of tying 
our characters closely to their envi- 
ronments and gameplay meant prototyp- 
ing low-resolution versions of our char- 
acters and their respective animations. 
Like coalmine canaries, we sent proto- 
models into our new levels to nose out 
potential animation, programming, and 
design problems. We relied on prototyp- 
ing throughout the course of our produc- 
tion as a means of refining a character's 
move set. This process of refinement was 
key to winnowing down unworkable 
ideas before animating a character's high- 
resolution incarnation. 

As a rule, our prototypes emphasized 
function over style. And although we set 
the aesthetic threshold low, these previsu- 
alization models still needed to be built 
and animated accurately enough to func- 
tion as valid test cases. For the anima- 
tors, this meant that prototype characters 
needed to jump to their correct heights, 
attack to their design specifications, and 
run at their proper speeds. 

Generally, we created prototypes using 
a character design sketch as a guide. 
These proto-characters were constructed 
with primitive objects and only roughly 
resembled their future incarnations, as 
you can see in Figure 1 (on page 32). 
Since previsualization models were so 
simple to construct, every animator 
could assist in building them, regardless 
of their modeling experience. Accuracy 
was required only in the representation 



of the character's height, proportions, 
and posture. 

For the most part, our prototypes had 
extremely simple skeletons: all geometric 
components were assigned to a single 
bone with no special deformation. 
Though such simplicity made for blocky- 
looking models, in practice our anima- 
tors had all the flexibility they needed to 
test out a move set. 

Animating our proto-characters was 
similar to sketching a traditional pencil 
test. Although animators were given a 
designer-approved move set, it was 
understood that animations needed only 
to be rendered into their roughest forms. 
One pass was often sufficient, as polish 
and overlap were unnecessary. 

The areas where precision did count 
were timing, measurement, and interac- 
tion with other characters. As they have 
the greatest direct impact on gameplay, 
these attributes were considered critical 
to testing a new character's behavior 
accurately. 

Timing has a major effect on both the 
readability of an animation and on game- 
play. From a distance, a poorly timed idle 
can look muddy. An attack animation 
can be too slow to make an enemy a 
worthy opponent, or too fast to be regis- 
tered. Emphasis or a lack thereof on just 
a few frames can make or break any ani- 
mation, especially within the short cycles 
of the real-time universe we were creat- 
ing. We discovered that by testing and 
fine-tuning our timings in the prototype 
stage, we could often avoid reworking 
polished animations on final characters. 
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FIGURES lA-C. The Dog Charger prototype was used to pretest the final character's animations, 
including its walk, run, and attack. FIGURE 2 (bottom left). The final Dog Charger model. 



Making sure that proto-characters 
adhered to design measurements was 
also important. For example, if the 
design document called for an enemy to 
attack at a range of 4 meters, animators 
would ensure that the prototype did 
exactly this. Designers could then get an 
accurate idea of whether an enemy trav- 
eled at the correct speed, was tuned to 
the appropriate difficulty, and was scaled 
appropriately in relation to the main 
characters. 

Prototyping also gave us a means of 
pretesting character behaviors and inter- 
actions. Whether it was with Ratchet or 
Clank, with the environment, or with 
another character, proto-models provided 
invaluable early glances at interactive 
behavior. For artists, programmers, and 
designers, previsualization served to tele- 
graph character behaviors both in terms 
of their technical feasibility and their 
gameplay value. 

Ultimately we found that our previsu- 
alization process was beneficial not just 
to animators but to our design and pro- 
gramming staff as well. It gave our pro- 
grammers a head start on coding game- 
play, while designers could test, tune, and 
ask for changes at a very early stage, 
allowing room for refinements. 

Prototyping saved animators time and 
energy that otherwise would have been 
spent painstakingly modifying or redoing 
final multi-pass animations. It provided a 
relatively simple means for evaluating 
character behaviors with respect to their 
timing, specifications, and interactivity. 
Moreover, it provided our animators 
with a practice run, complete with feed- 
back, before moving on to a high-resolu- 
tion character (Figure 2). 

MEL Shortcuts: 
Automating Our Setups 

Maya Embedded Language (MEL) 
scripts were essential for bridging 
the gap between the level of complexity 
we desired and the time we had sched- 
uled to implement it. Through MEL 
scripts, we were able to streamline setup 
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operations, customize animation 
processes, and level our technological 
playing field. 

Two such scripts (examined later in 
this article) allowed our team to take 
advantage of driven key functionality 
that otherwise would have been too 
cumbersome to animate or too tedious 
to rig by hand. Another tool enabled our 
artists, regardless of technical experi- 
ence, to fit characters with IK systems 
automatically. 

Most of our bipedal characters had leg 
setups like the one pictured in Figure 3. 
As seen in the hierarchy (Figure 4) our 
legs had standard hip, knee, and ankle 
joints, a heel joint, and two to three 
bones in the feet. (For clarity purposes, 
please note that we referred to our foot 
bones as "toes.") 

Our IK-rig consisted of three to four 
RP (Rotate Plane) IK-handles. These con- 
nected hip-to-ankle, ankle-to-toe, toe-to- 
toe and/or toe-to-null. All were config- 
ured into a hierarchy (Figure 5) that 



specified relationships between the IK- 
handles, a set of locators, and several 
NURBS constraint objects. 

Though relatively simple, setting this 
IK-system up by hand for every NPC, 
enemy, and prototype would have taken 
more time than we had. Moreover, we 
knew that this time would be better 
spent bringing our characters to life. 

An actual tools programmer might 
scoff at the artist-authored MEL script 
we developed to make our leg chains. In 
the end, however, our "IK Setup Tool" 
reduced an hourlong technical chore to a 
simple task that took seconds. Further- 
more, the script did not require setup 
expertise, and our relatively simple code 
could be customized and refined entirely 
from within the art department. 

Using the IK Setup Tool (Figure 6) 
was a three-step process. First, an artist 
checked their characters' leg joint names 
against the tool's presets, making any 
necessary changes. Next, a scale factor 
for the constraint objects was entered, 
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FIGURE 3. This leg setup was used for most 
bipedal characters, saving tedious hand-setups 
for IK systems for individual characters. 



based loosely on a character's size. The 
artist then hit nine buttons in sequence. 
These buttons would auto-attach the IK 
handles and instantly build the con- 
straint hierarchy. 

Dissecting the IK 
Setup Tool 

MEL is a quirky and often inconsis- 
tent language. A good portion of 
the time we spent developing our IK 
Setup Tool was used to track down the 
proper commands for the tasks we need- 
ed to execute. Still, we managed to 
uncover the MEL commands we needed 
to actuate the core tasks of each of our 
nine tool buttons. 

The first button's purpose was to 
place IK handles on a character's legs. It 
read the names of the bones from the 
top text fields by using the textFieldGrp 
command in its query (-q) mode. These 
string variables were then passed to the 
ikHandle command, which in turn created 
the IK handles. 

The second button placed NURBS 
cones on a character's hip, ankle, and 
toe joints. These cones, created using 
MEL's cone command, were the primary 
constraint objects an animator would 
use to manipulate the legs. The xform 
command was used to query (-q) the 
positions of the leg bones and store them 
as variables. The move command then 
read these variables and moved the 




FIGURE 4. Standard hierarchy for a charac- 
ter's leg, as shown in the Hypergraph. 




FIGURE 5. The leg constraint hierarchy viewed 
in the Hypergraph, showing connections 
between the IK handles, locator set. and 
NURBS constraint objects. 



cones into place. Finally, MEL's 
pointConstraint locked the hip cones to 
the character's hips. 

Pressing the third button called 
CreateLocator to place a pair of locators in 
the scene. Next, the group command 
grouped the locators to themselves. Then 
xform (-q) queried the positions of the 
character's knees, and move translated the 
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FIGURE 6. The IK Setup Tool streamlined 
repetitive, error-prone setup procedures and 
kept customization within the artists' hands. 

two new parent objects to the knee joints 
and the locators to positions in front of 
the knees. 

Button number four configured the 
cones, locators, IK handles, parent 
groups, and constraints into a standard- 
ized hierarchy via the parent command. 
Again, the new groups were translated 
into place using move. New constraint rela- 
tionships were created between the knee 
locators and main leg IK handles, and the 
new constraint hierarchy and the skele- 
ton. These were implemented using the 
poleVectorConstraint and scaleConstraint 
commands, respectively. 

Button five added several expressions 
to the scene, saving us data-entry drudg- 
ery. We added expression code for speci- 
fying both constraint and skeletal 
behavior using the expression command, 
allowing us to automate both the cre- 
ation and the specifications of our setup 
expressions. 

Number six altered the rotate order of 
the heel and toe NURBS cones from 
XYZ to YXZ using setAttr. We had pre- 
viously determined that this rotate order 
produced the most reliable rotations in 
our quaint Z-up environment. 

Buttons seven through nine performed 
some final housekeeping tasks. Button 
seven grouped custom rotation guides to 
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FIGURES 7A-C. Joint scaling and translation offered animators direct manipulation of poses and gave characters' moves extra verve for the modest 
cost of a low-tech solution. 



a character's spine using the polyCube and 
parent commands. Button eight used 
setAttr to ensure Maya's segment scale 
compensate was switched off for all of a 
character's joints. Finally, button nine 
keyed a reference frame at -10 on the 
character's skeleton and constraint hier- 
archies using setKeyf ratne. Listing 1 (page 
34) shows some of the MEL procedures 
we found most useful. 



LISTING L Some helpful MEL procedures. 



Automating this process with MEL 
both saved us time and eliminated the 
steps most prone to human error. 
Furthermore, by enabling any artist, 
regardless of their setup experience, to fit 
a prototype and/or character with a func- 
tioning IK system quickly, we alleviated 
bottlenecks. This conservation of both 
time and human resources saved energy 
that could then be devoted to artwork. 



Low-Tech Animation 
Solutions 

The shortcuts and prototypes I've 
described so far shared a common 
purpose: to help us create better anima- 
tion more efficiently. Both of these 
methods accomplished this by either by 
telegraphing problems or by saving 
time. Often, however, we would spurn a 
high-tech solution due to its specificity, 
inefficiency, and/or complexity. And still 
at other times, we embraced traditional 
CG taboos. 

We consistently and repeatedly trans- 
lated and scaled our characters' bones. 
True, most of us learned on our grand- 
mothers' knees never to do that to a CG 
character. "Use your constraints," she 
would say. "Rotate your bones if you 
must. But avoid scaling them, and don't 
ever, ever let me catch you in a transla- 
tion!" We all love our grandmothers, but 
we found that the tenets of traditional 
animation called for — nay, demanded 
— that we defy her. 

The reason behind our disobedience 
was squash and stretch. We found that 
by scaling our joints, and especially by 
translating them, we could instill our ani- 
mations with extra gravity and snap. 
Major translations often lasted only a 
couple of frames and, borrowing an idea 
from Disney, were "more felt than seen." 

Since we had no IK setups to speak of 
on the spines and arms of our characters, 
translating the bones in these body parts 
was quite simple. If needed, we could key 
the leg IK solvers "off" in order to 



//A method for querying a bone's position in world space: 
xform -query -worldSpace -translation my_joint_name; 

// A method for querying the contents of a text field: 
textFieldGrp -query -text my_text_field_name; 

// A method for setting a keyframe at frame -10 on a hierarchy: 
setKeyframe -time -10 -hierarchy below my_hierarchy_name; 

// Basic transformation methods: translation, rotation, and scaling: 

// Moves an object to (0,0,5): 

move -absolute 5 my_object_name; 

// Rotates an object by 90 degrees on Z, 
// relative to its current Rotation: 

rotate -relative 90 my_object_name; 

// Scales an object to 3 times its current size: 

scale -relative 3 3 3 my_object_name; 

// (Note: AH flags are listed in their long forms.) 
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FIGURES 8A-C. The Walk Guide helped line up characters' feet on the ground properly every frame to minimize unattractive foot slidir 



manipulate these joints. Translation and 
scaling were effective across the board 
and worked wonders on anything from 
walks to attacks to facial animation 
(Figures 7a-c). 

Requiring no additional setup, these 
low-tech solutions saved us time. Within 
hmits, this method of animation provid- 
ed animators with a direct, tactile, and 
expedient method of sculpting their char- 
acters' poses. Although unglamorous, 
this technique was as effective as any in 
terms of preserving our resources and 
improving our animations. 

Walks and the Walk 
Guide 

Another device we used to aid our 
animation was called the Walk 
Guide. We used this tool help our char- 
acters' feet stick to the ground during 
walk and run animations. Although foot 
slippage is commonly forgiven in the 
world of games, we hoped that by elimi- 
nating it we could add an extra dimen- 
sion of behevability to our characters' 
locomotion. 

The Walk Guide was an elongated 
cube with many smaller cuboids attached 
to it. The smaller cuboids were identical 
to the polygonal markers on our charac- 
ters' ankles and toes, which were 
grouped to their feet during setup. 

By scaling a special parent node, the 
Guide's small cuboids could be adjusted 
to match a character's foot size. ScaUng 
the large cuboid allowed an animator to 
accommodate for the character's stride 



length. A set of constraints and locators 
ensured that as the stride length changed, 
the preset foot size remained constant. 

Since our walk cycles were animated in 
place, we needed a way in which to sim- 
ulate forward movement while keeping 
track of the positions of a character's 
feet. The solution was to animate the 
Walk Guide to the speed specified by the 
designer (2 meters per second, for exam- 
ple). Once the Walk Guide was moving 
at the proper speed and the small 
cuboids correctly scaled, an animator 
could begin working on the character's 
walk cycle. 

The trick to using the Walk Guide to 
eliminate foot sliding was to keep the 
character's foot markers lined up with 
the small cuboids on the Guide. This 
applied for every frame in which the 
foot made contact with the ground (Fig- 
ures 8a-c). 

Upon a cycle's completion, a character 
could be put into a level and moved at its 
preset speed with little or no foot slip- 
page. Additionally, programmers could 
scale the playback speed of the cycle rela- 
tive to the character's velocity and still 
have the feet stay grounded. 

There were several gameplay situations 
that were not as clean as the test case I 
just described; however, the Walk Guide 
did serve to plant our character's feet 
properly in most of our worlds. Once 
accustomed to the Guide, we animators 
found that using it benefited both our 
schedule and our artwork, as it kept 
track of the more technical aspects of 
locomotion for us. 



Making Faces: 
Artistic Reasons and 
Technical Details 

We knew from the start of devel- 
oping Ratchet & Clank that 
facial expression would be an important 
component not just to our cinematics 
but to our gameplay animations as well. 
Once again, we were faced with the 
dueling goals of animation depth and 
scheduling efficiency. We settled on two 
methods for making faces: one simple 
one for our enemies and one more com- 
plex for our heroes. Expressions exag- 
gerated the idles, intensified the attacks, 
and sealed the deaths our of enemies 
and heroes alike. 

When animating our enemies, we drew 
on a traditional animation dictum: A 
viewer of animation is usually drawn to 
a character's face, particularly to the 
eyes. Attention paid to a character's eyes 
and mouth was very important to mak- 
ing convincing actions, especially during 
our quick gameplay cycles. 

Most enemy characters had fairly sim- 
ple face skeletons. However, these skele- 
tons allowed for a high degree of manip- 
ulation of the eyes and mouth. Each eye 
had between two and four bones con- 
trolling its brow and lids. Mouths were 
generally simpler, using only one or two 
bones. In most cases, this setup gave us 
all the flexibility we needed to exagger- 
ate the enemy's features and thus height- 
en the emotion of its actions (Figures 9a 
and 9b). 

Our heroes' faces had a more sophisti- 
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cated setup, which they shared with the 
NPCs. Though NPC faces were manipu- 
lated mostly in our cinematics, RATCHET 
& Clank made heavy use of expression 
during gameplay, as well. 

Like the enemy setups, hero and NPC 
faces were manipulated via their face 
joints. Unlike the enemies', these joints 
were animated though a driven key sys- 
tem instead of being transformed direct- 
ly. Since they clocked more screen time, 
hero and NPC faces tended to have a 
far greater amount of bones — and 
hence expressive range — than their 
enemy counterparts. 

Figures 10a and 10b show some of the 
range of expression Ratchet and Clank 
exhibit during gameplay. He smiles when 
excited, grimaces when he's hit, grits his 
teeth during combat, chatters them when 
he's cold, and drops his jaw when he 
dies. Clank's expressions change both 
while he's strapped to Ratchet's back and 
when he's played independently. 




As I mentioned earlier, hero and NPC 
expressions were animated by combining 
preset driven key attributes via a MEL 
script slider interface. These presets 
allowed the animator to combine and 
create a wide array of facial expression 
without having to build them from 
scratch. Like color primaries, these 
attributes could be blended together to 
form new combinations. 

About half of a character's 40 or so 
facial attributes were dedicated to pro- 
ducing a basic expression, either on all 
or on parts of the face. These basic 
expressions included anger, disgust, fear, 
happiness, sadness, and surprise, all of 
which would be easily recognizable to a 
player. More subtle attributes were dedi- 
cated to animating phonemes and con- 
trolling individual facial features. 
Unique and varied emotional ranges 
could then be achieved by combining 
expression, phoneme, and feature attrib- 
utes together. 




Scripting Facial 
Presets 

Assigning facial presets to our char- 
acters cost us some setup time. 
However, we were able optimize some of 
the processes with another MEL script. 
Like our other MEL tools, this script 
automated some of the tedious steps, 
allowing a setup artist to spend more 
time on the art of sculpting facial poses. 

Facial presets were created in a sepa- 
rate animation file, where each expres- 
sion, phoneme, or feature pose was 
stored as a separate keyframe. Upon 
completing this file, a character artist 
would use our MEL Driven Key Genera- 
tor (Figure 11) to set the driven keys 
automatically for each pose. 

The Driven Key Generator worked by 
comparing the transformations of the 
keyframed pose to those of a default. 
When the script registered that a channel 
had changed from the default, it would 
set a driven key on that channel based 
on its changed value. The script relied 
on MEL's arithmetic functions to identify 
value changes, and its setAttr and 
setDrivenKeyf ratne commands to activate 
the drivers. Listing 2 shows some of the 
Driven Key Generator's sample code. 

The drivers for our facial animations 
were stored on a model called the 
Control Box, shown in Figure 12. This 
hierarchy of cubes served as a visual out- 
line of facial attributes, and could also 
double as a second interface. For efficien- 
cy's sake. Ratchet, Clank and all of our 
NPC characters had identical Control 
Boxes, though Ratchet's had many more 
active drivers. 

We found our automated setup 
method to be advantageous for three rea- 
sons. First, it saved a setup artist from 
having to manually identify and key 
bones, channels, and drivers. Second, it 
assigned driven keys to changed channels 
only, leaving any non-affected channels 
free for animators to keyframe. Finally, it 
circumvented Maya's built-in driven key 
interface, which we found to be cumber- 
some and even unreliable when simulta- 
neously assigning multiple bones and 
channels to a driver. 



FIGURES 9A & 9B. With enemy face skeletons, less was more. Bone detail was reserved for the 
eyes and mouth to enable simple, exaggerated expressions. Here, during an in-game animation, 
the Robot Paratrooper's face reacts to being knocked down. 




FIGURES 10A-B. Ratchet and Clank's gameplay facial animation system (also used for NPCs) 
needed more sophisticated setups than enemies' for the broader range of expression they were 
required to show during gameplay 
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Regardless of method, facial animation played a 
vital role in breathing life into our gameplay char- 
acters. Again, MEL was instrumental both in 
granting our artists access to an advanced Maya 
feature, and in optimizing our workflow. Whether 
a hero or an enemy, virtually every character per- 
sonality in our game was strengthened through 
facial expressions. In turn, this enhanced interac- 
tions both with players as well as between the 
characters themselves. 



End of Cycle 



Like all character-driven projects, RATCHET & 
Clank presented our animation team with a 
unique set of artistic and technical challenges. Our 
artistic philosophy was built on the understanding 
that our characters were the instruments though 
which a player would experience our universe. We 
knew that in meeting these challenges, our puppets 
would transcend mere game space and become the 
entities that our players would identify with, vilify, 
and even personify. 

However, this philosophy needed to be coupled 
with practical methodology if it was to see our 
project to its conclusion. From this necessity grew 
our testing practices, MEL shortcuts, and real-time 
animation procedures. Throughout production, 
these methods removed many of the barriers that 
would otherwise have obstructed the artistic efforts 
of our animators. 

As the Insomniac team cycles into our next proj- 
ect, we continue to refine and expand upon the sys- 
tems and procedures we developed during Ratchet 
& Clank. Though our procedures continue to 
evolve, our underlying goals remain unchanged. For 
in the end, we can only prove a technology's worth 
by an audience's response to our characters. ^ 



LISTING 2. Sample code from the Driven Key Generator. 



// The "if" gate checks for changed X-Translation values 
// between the Default and Posed frames. 

if ($txa != $txb) 
{ 

// Sets the Driver Attribute and the Current Joint's 

// X-Translation to their Default Values; 

// Sets a Driven Key Frame for the Default Values. 

setAttr $atnm $drO; 
setAttr (Scurrent + ".tx") $txa; 
setDrivenKeyframe -currentDriver $atnm -attribute 
translateX $current; 

// Sets the Driver Attribute and the Current Joint's 

// X-Translation to their Posed Values; 

// Sets a Driven Key Frame for the Posed Values. 

setAttr $atnm $drl; 
setAttr (Scurrent + ".tx") $txb; 
setDrivenKeyframe - currentDriver $atnm -attribute 
translateX $current; 

// Prints command summary to the Script Editor for 
// easy reference. 

print ($current + ": TX has been keyed for slider 
value 0: " + $txa + " and slider value 10: " + 
$txb); print " \n"; 

} 

//In this loop segment, $current is the current joint, 
// and $atmn is the attribute name. $drO and $drl represent 
// Default and Posed Driver values. $txa & $txb are the 
// Default and Posed X-translation values, respectively. 

// (Note: All flags are listed in their long forms.) 



DEFAULT FRAME [o" 
POSED FRAME [iSiO 



DRIVER NAME phonemes^A^" 
DEFAULT VAJJUE fj 
TyVFuGET VALUE |Tu 



TOPDRIVEW JOfcTT 



LOAD DRIVER 



SET COMPLEX KE^- 



FIGURE 1 1 . The Driven Key Generator analyzed 
a preset facial pose, compared it to a neutral 
pose, and assigned driven keys to the affected 
channels. 
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tH EyesI 



Expression 



FIGURE 12. Each NPCand hero had its own 
Control Box on which its facial drivers were 
stored. Facial drivers were actually attributes of 
the Control Box's cubes. 
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FOR MORE INFORMATION 



BOOKS 

Gary Fagin. The Artist's Complete Guide 
to Facial Expression. New York: Watson- 
Guptill Publications, 1990. 

Frank Thomas and Ollie Johnson. The 
Illusion of Life. New York: Hyperion, 1981. 

RECOMMENDED MAYA TRAINING 
MEL Fundamentals (formerly MEL for 
Artists): Information available at 
www.aliaswavefront.com. click on Maya 
^^^aining under "Education" 
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The 17th Game Developers Conference convenes 
again in San Jose fronn March 4 to 8 this yean and 
conference organizers find thennselves in a 
quandary sinnilar to that faced by nnany of their 
attendees: overconning sequelitis. Like nnany devel- 
opers working in todays sequel-driven nnarketplace, their chal- 
lenge lies in satisfying returning custonners who expect certain 
features and experiences that nnade forerunners popular while 
innovating and refining enough to attract new custonners and 
add value for those returning. 



From content spanning the different conference tracks 
to the extracurricular parties and events, the organiz- 
ers. CMP Media's Ganna Network (which also publish- 
es Game Developer), and the GDC Advisory Board 
have focused their efforts on honing GDC into an 
indispensable event for ganne developers. The events nnarket is 
still feeling the effects of 9/1 1 and the econonnic slowdown, and 
nnany developnnent studios that used to spring for annual trips to 
GDC. E3. and Siggraph are now scaling back their budgets to 
include just one or two events for ennployees. Others nnake the trip 
on out-of-pocket expenses, hoping that glittering pitch denno or 
polished resunne will pay off big returns. Sonne critics contend the 
event has beconne too "corporate." leaving the needs of snnall inde- 
pendents, and even the event's own grassroots beginnings, behind. 

Taking into account the changing needs of a rapidly evolving 
industry, organizers are always looking at new opportunities to 
ratchet up the value of the event. The advisory board has nnade 
careful iterations in the content goals of the various conference 
tracks, while ennerging nnarkets are finding new pronninence 



through progranns such as the two-day GDC Mobile event. 

Creating a stronger sense of developer identity is innportant. 
too. The International Ganne Developers Association (which func- 
tions as an independent nonprofit under a nnanagennent contract 
with the Ganna Network) develops its own conference track 
focused on developer and connnnunity issues, and the IGDA 
returns with the third annual Ganne Developers Choice Awards, a 
progrann that ainns to create nneaningful peer recognition for ganne 
developers. Meanwhile, the Independent Cannes Festival, now in 
its fifth yean continues to groonn itself into a showcase for innova- 
tive indie ganne projects. 

Aside fronn the din of the GDC Expo floor the blur of parties, and 
the innpronnptu encounters in the hallways, the heart of GDC 
rennains in the nnore than 300 lectures, panels, and roundtables 
presented, and in the speakers who variously swinn or sweat 
through their Powerpoint slides for the betternnent of industry 
knowledge. We caught up with a few of this year's speakers to find 
out what they have in store for attendees and what they as atten- 
dees think of this ever-evolving event. 
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GDC attendees descend on the Expo floor as the doors open. 



ADAM SCHNITZER 
Senior Artist, LucasArts 

Visual Arts Lecture: "How to Build a Better Cutscene" 

Game Developer What will your session cover? 

Adam Schnitzen I'll talk about the reasons for doing 
cutscenes, how to plan your cutscenes, the importance of pre- 
visualization, and the ins and outs of how to transition from 
gameplay to cutscene and back again. I will also spend a little 
time talking about production methods that can streamline the 
cutscene creation process. Because my background is as a lay- 
out artist at Pixar, my perspective is that of someone who is 
very concerned with cinematic design, so much of my talk will 
focus on that as well. 

GD: How do you see the role of cutscenes in games changing in the 
next few years? 

AS: There are so many different styles of games, it's hard to 
predict with certainty what the role of cutscenes will be. But for 
a certain style of story-based game, they are indispensable. 
With game engines getting more and more sophisticated, and 
the consoles allowing us to create more filmlike environments, I 
can envision more immersive cutscenes and more seamless tran- 
sitions in and out of cutscenes. With these higher-resolution in- 
game environments that are evolving, we will eventually be able 
to dispense with prerendered cutscenes altogether, but I would 
guess that that day is still five to 10 years off. 

GD: The name of your session implies — fairly — that there is ample 
room for improvement in the quality of game cutscenes. Why do you 
think this area continues to vex developers? 

AS: It's important to be very clear on the purpose of the 



cutscene for your particular game. Cutscenes can do a lot to 
enhance gameplay, but gameplay always comes first. Having said 
that, I think there is a lot of ignorance of the fundamental princi- 
ples of cinema in the game world. These are principles which 
were codified and haven't changed for the past 70 years or so. 
And when you go from gameplay to cutscene, you are stepping 
into the arena of cinematic storytelling. A greater awareness of 
cinematic structure and the power of the camera would help 
bring cutscenes to a higher level. 

GD: How many years have you been going to GDC? 

AS: This is going to be my first year at GDC. 

STUART ROCH 

Executive Producer, Shiny Entertainment 

Production Lecture: "My Matrix Experience: A Survival Guide to 

Working with Movie Licenses" 

GD: What will your session cover? 

Stuart Roch: While working on the Matrix project, the film's 
interactive producer and I often talked about what a shame it 
would be if, once the project was completed, all the knowledge 
she and I had gained about the marriage of Hollywood and the 
gaming industry were to be lost. We actually felt a little bad, fig- 
uring that others in the business might be forced to learn through 
trial and error as we have had to these past couple years. So I 
hope to share all the lessons we have learned, so others in the 
industry can get a step up on a future licensed game. I'll cover 
everything from the initial deal all the way through the postpro- 
duction process. 

GD: What are the communication challenges developers face when 
working with a movie studio on a licensed property? 

SR: A number of communication problems can arise, from 
making sure the movie and game companies use the same ter- 
minology to describe issues, to coordinating schedules 
between two entertainment mediums whose pre- and postpro- 
duction schedules don't mesh very well. Perhaps the biggest 
communication problem that can arise is when a developer 
can communicate to the directors only by going through the 
studio office. This indirect communication channel can lead 
to delays and potential misinformation. In our case, the 
Wachowski brothers recognized this potential problem and set 
up communication channels directly between themselves and 
Shiny to make sure that accurate information and assets were 
flowing as efficiently as possible. 

GD: Do you feel that your experience on the Matrix project carries 
over well for future endeavors? 

AS: Not only has the development process been easier than 
we expected due to the unique communication channels, but 
we've all learned a lot about how Hollywood approaches simi- 
lar development problems, and we applied some of their solu- 
tions to our development process. Hollywood is a mature 
industry, and through my session, I'll be sharing some of their 
techniques which may be of help to other developers. 
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GD: What have been the most significant 
changes to GDC since you began attending? 

AS: The most significant changes I've 
seen at GDC are its growth international- 
ly and the fact that we have so many 
respected overseas speakers flying over to 
share their knowledge and experiences. 
There's also been an incredible growth in 
new talent looking to work in this indus- 
try. GDC gives those people a chance to 



widen their perspective and really see 
what it's all about. They can meet the 
people that are making the games, they 
can meet some of the people they look 
up to, they can be inspired by the creativ- 
ity of others, and they can take away 
concrete advice. 

GD: What's your favorite event at GDC? 
What's your least favorite thing about GDC? 

AS: I always really enjoy the lecture 



sessions. Unlike other industry shows 
throughout the year, this is the one stop I 
make where I always have useful take- 
away from my industry peers. You never 
feel as though the time spent at GDC is 
time wasted. The thing that always seems 
to be a problem with GDC is that it 
inevitably coincides with some sort of 
crunch time on one of our projects. 

KATIE SALEN 

Independent Game Designer 
ERIC ZIMMERMAN 
CEO, gameLab 

Game Design Lecture: "Breaking the Rules 
of the Game" 

GD: What will your session cover? 

Katie Salen: We are presenting a lecture 
on rule-breaking and its relevance for 
game design. Like it or not, rule twisting, 
bending, and breaking are part of games 
— but rule-breaking can be positive or 
negative, and game designers have a lot 
to learn from it. We will look at the for- 
mal, social, and cultural ways that players 
break rules and how rule-breaking can be 
integrated into the game design process. 

GD: Why do players want to break the rules? 

KS: Players break rules for all kinds of 
reasons, but they generally do so not to 
break or end the game. Instead, most cre- 
ative forms of rule-breaking introduce 
excitement, variety, strategy, and fun into 
the game. 

GD: What will your session cover? What can 
game designers learn from rule-breaking? 

KS: Because games are systems, it is 
always possible for players to drive a 
wedge into it, bending the system into a 
new shape by breaking the rules. We chal- 
lenge game designers to find ways of 
including this natural desire of players 
into their game designs. When given the 
right tools, players will transgress the rules 
of the game in pursuit of alternate forms 
of expression. How can this desire be 
enhanced or slowed, modified or trans- 
formed, by the design of the game itself? 
This is what we will explore in our talk. 

GD: How many years have you been going 
to GDC? What has been the most significant 
change since you began attending? 

Eric Zimmerman: My first GDC was 
1998. It was the year in Long Beach 
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when the entire conference played a giant 
game of dart-gun Assassin. The confer- 
ence has lost that kind of wonderful 
folksiness, but that is inevitable as the 
industry grows. For the last two years at 
the GDC, gameLab has tried to bring 
back a bit of that spirit with our own 
massively multiplayer off-line games 
(Bite Me in 2001 and Leviathan in 
2002). Look for our new game this year 
in the IGDA booth. 

GD: What's your favorite event at GDC? 

EZ: The best moments at a conference 
always happen in the interstices between 
the organized talks, meetings, and par- 
ties. Surprise encounters between ses- 
sions, gab sessions at cheesy hotel bars, 
and late-night hotel-room game design 
debates are what make GDC so fantastic 
for me. I just wish there was more time. 

JAKE SIMPSON 

Psychology Programmer, Maxis 
Programming Lecture: "Animation System 
Implementation: What Works and What 
Doesn't" 

GD: What will your session cover? 

Jake Simpson: My session involves dis- 
cussing approaches to building state-of- 
the-art animation systems, heavy on the 
practicalities of what works and what 
doesn't, what's worth experimenting with 
and what's not. This information is 
drawn from experience in working with 
animation systems for third-person 
games (Heretic II), and creating new 
animation systems for networked first- 
person games (Ghoul 2 for Soldier of 
Fortune II and Jedi Knight II) and for 
next-generation SiMS products. 

GD: What's the single biggest takeaway you 
got from developing Raven's Ghoul system 
that you think can save developers time in 
planning animation system features? 

JS: "Give the animators and coders 
more time to learn how to use the new 
technology." Game development being 
what it is, it usually takes two or three 
games before new technology matures 
enough for content creators to really 
know where the limits are and how to 
use it all in the most efficient manner. 
The earlier you get the tech in the hands 
of the content creators, the better-look- 




United Game Artists' Tetsuya Mizuguchi 
demonstrates Rez during a game design lec- 
ture at last year's GDC. 



ing and more spectacular the results will 
be. Great tech depends on artists and 
content creators building stuff that uses 
it to the best of its ability — you need 
everyone to be on the same page for it 
all to come together. 

GD: How many years have you been going 
to GDC? What has been the most significant 
change since you began attending? 

JS: I've been going for about four years 
now. From where I sit, the most signifi- 
cant thing is what the GDC Advisory 
Board is doing. They've made such an 
effort this year to try to be specific in 
what they present, in terms of actually 
getting value out of the lectures. I figure 
if I have to take notes at a lecture, then 
it's worth my time, and they seem to be 
going all out for this effect this year. 

Also, every year I feel like we are start- 
ing to get more attendees from the rest of 
the world, notably the Japanese. We all 
have something to learn from people who 
have such mastery of our craft, and I for 
one applaud this international flavor. 

GD: What's your favorite event at GDC? 
What's your least favorite thing about GDC? 



JS: My favorite events are the informal 
get-togethers that happen after lectures 
and roundtables. Being able to pigeon- 
hole people with proven experience 
about a specific issue you may be having, 
or even just bending their ear about 
something that interests you, is great. It 
saves time, wasted research effort, and 
usually nets a suggestion you would 
never have had yourself. 

Least favorite? Well, lets be honest, 
it's the hangover each morning. What's 
a GDC without some company-spon- 
sored parties? 

DAN SCHERLIS 
CEO, Etherplay 

Business and Legal Lecture: "Doing 
Business with the Telecom Industry: 
Understanding Their Deal Terms, Culture, 
Rites, and Ritual" 

GD: What will your session cover? 

Dan Scherlis: Many developers are fasci- 
nated with mobile games, for many good 
reasons. And many developers are have 
trouble getting attention from telecom 
types, not to mention getting deals and 
getting paid. I am not being glib in the 
session title; I do feel that the major issues 
are downright anthropological. The two 
industries speak and act differently. 

GD: What has the telecom industry learned 
about game developers in the past yean and 
has it altered their approach to these new con- 
tent creators at all? 

DS: Telecom has been a motivated and 
attentive student of games and of game 
developers. In the last year I have heard 
far less talk of games as a commodity 
and more respect for the value of quality 
product. This is bringing about better 
deal terms. 

That said, we are still of different 
worlds, and there is so little history of 
deal-making between us that we do not 
have much precedent for basic terms and 
structures of our deals. 

GD: What's the single biggest gotcha that 
awaits game developers making their first 
foray into dealings with telecom companies? 

DS: Communication — especially style 
of communication: Game developers use 
whiteboards; telecom types use 
PowerPoint. 
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Also, a developer should not assume 
that a telecom executive knows anything 
about games. If you offer an RTS with 
FPS action but RPG depth, with down- 
loadable mods and ortho view, you will 
not be understood. If you give examples 
like Warcraft, Half-Life, and Final 
Fantasy, you will continue to strike out. 
Test your pitch on a smart nongamer. 
Your parent or spouse will have too much 
of a clue. Try your dentist or accountant. 

GD: There have been many losses, and 
much pain, amongst mobile-game startups. 
Where do you see an opportunity for profit 
from mobile game development? 

DS: Mobile games are echoing the his- 
tory of Internet games. We see many 
basic mobile games, which are hard to 
differentiate. Over the Internet, we saw 
many ad-supported games, few of which 
earned good money for their developers. 
The games that make big money online 
are fundamentally different: they are of 
premium quality, their designs exploit 
the network and include persistent social 
structures, and they have subscription 
economics. I believe that this description 
will apply to the most profitable mobile 
games. This is why several online-game 
veterans are being attracted to mobile 
platforms; we see an opportunity to 
build profitable communities, without 
the multi-million-dollar, multi-year 
development cycles. 

The greatest challenge is to the design- 
er. We need to design explicitly for this 
new medium, rather than trying to sell 
either shovelware or obvious but deriva- 
tive and shallow distractions. 

GD: How many years have you been going 
to GDC? What has been the most significant 
change since you began attending? 

DS: I started attending GDC in 1992, I 
think, when I joined Papyrus. I've missed 
only one or two since then. 

The most dramatic change has been 
the astounding growth. As the common 
complaint goes, this growth threatens the 
sense of community and collegiality that 
attracts many long-time attendees. 

I can gripe with the best of them, but in 
fact I have been pleased by the degree to 
which the community survives. The San 
Jose Convention Center has been a chal- 



lenge, many industry veterans stay home, 
and the sheer size is daunting, but I am 
always delighted by the many chance 
encounters with colleagues at GDC. 

TOMMY TALLARICO 

President, Tommy Tallarico Studios 

Audio Panel: "Orchestral Panel" 

GD: Who's on the panel and what do you 
hope to cover? 

Tommy Tallarico : We will have some of 
the best orchestral composers for the 
videogame industry on the panel: Jack 
Wall (Myst III), Clint Bajakian (of 
LucasArts fame), Jeremy Soule (Harry 
Potter), Bill Brown (Rainbow Six), and 
Dan Irish (producer of Myst III). We 
may also have a few special guests and 
surprises! 

Last year's orchestra panel was really 
tailored toward composers. This year we 
felt it very important that the producers 
and designers know about live orchestral 
sessions as well, so we are tailoring it 
more for them. Budgets, production dos 
and don'ts, how to convince your boss, 
the real value of using live players, union 
vs. buyout, as well as other things, will 
all be covered in this panel. It is impor- 
tant for the project decision makers, 
milestone schedulers, and purse-string 
holders to find out how to go about get- 
ting live music in their projects. 

GD: How do you think producers and audio 
professionals should best go about deciding 
when to use orchestral performances in 
games and when not to? 

TT: Style of music and game genre is 
one big contributing factor. Not every 
game warrants live orchestra, but most 
would benefit greatly because of it. 
Publishers are looking to differentiate 
themselves to the consumer from a quali- 
ty standpoint, and using a live orchestra 
can help do that. Live orchestras don't 
cost hundreds of thousands of dollars to 
produce, either — there are many differ- 
ent alternatives. You can't get a 50-piece 
live orchestra recorded for less than 
$1,000 per minute of music. 

GD: How many years have you been going 
to GDC? What has been the most significant 
change since you began attending? 

TT: I used to sneak in and just go to 



the parties since 1993. Then I got smart 
and became a speaker. The biggest 
change besides the obvious sheer number 
of people would be the emergence of a 
huge audio community coming out to 
GDC. In the early years you could count 
the number of audio people on three 
hands. Since the Audio Pass was created, 
hundreds of interested audio profession- 
als and nonprofessionals have come 
seeking knowledge and understanding of 
this crazy profession. In audio you have 
to deal with three important elements in 
production: creative, technical, and busi- 
ness. GDC is a place you can go to learn 
about all three. 

GD: What's your favorite event at GDC? 
What's your least favorite thing about GDC? 

TT: My absolute least favorite thing 
about GDC is trying to get a room every 
year. My favorite event is the Game 
Developers Choice Awards ceremony. It's 
really nice to see the developers get the 
recognition they deserve from their peers. 

For the most up-to-date GDC 2003 
information visit www.gdconf.com. ^ 




Lionhead's Richard Evans accepts last year's 
Game Developers Choice Award from the 
IGDA for Excellence in Programming, for his 
work on Black & White's AI. 
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Developing Sequels: 

The Designer's 

Dilemma 






Ensemble Studios' 



One is pretty hard. There are a lot of things to 
attempt and reject, a lot of mistakes to make, a 
lot of lessons to learn. Without a prior success 
(or even a prior failure) for comparison, much 
of your design relies on instinct. Without an 
experienced team, much of your schedule operates at dart- 
board-level accuracy. Figuring out both how to work around 
long-expected pieces that don't pan out and how to capitalize 
on unexpected miracles is a big part of the job. Mix these fac- 
tors in with the usual chaos surrounding a game company on 
her maiden voyage and you have a situation often referred to 



Two is easier, although you may no'^^in^^-^STthe time. 
With your first game out in the wild, you're able to get real- 
world feedback on what worked and what didn't. You know 
more about your team and ideally have a familiar engine and 
tool set to work with, providing you with a much better idea of 
what's possible. Additionally, from the lazy designer perspective, 
half of your feature set is waiting for you at the start of the proj- 
ect — everything you ran out of time for on the first game. 

Three is the end of the world. By this time you've amassed a 
good understanding of what people like about your games. 
Unfortunately, you also have fans who've played two titles in 

s, and are starting to grumble 



MPIRES. in rJis spare 



IAN FISCHER I Ian joined Ensemble Studios as a designer in 1997, just in time for the final stages of AGE OF 1 
time he likes playing games and arguing. He can be reached at ifischer@ensemblestudios.com. 

GREG STREET I Greg was a marine biologist up until he discovered Age of Empires in 1998 and ended up joining Ensemble Studios 
to work as a game designer. Feel free to send your marine crusatcean questions to gstreet@ensemblestudios.com. 
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GAME DATA 

PUBLISHER: Microsoft 
NUMBER OF FULL-TIME DEVELOPERS: 
50 total employees. 15 programmers 
CONTRACTORS: 10 quality-assurance 
contractors, no contract programmers 
LENGTH OF DEVELOPMENT: 
30 months 
RELEASE DATE: 
October 31 2002 
TARGET PLATFORM: PC 
DEVELOPMENT HARDWARE: From 
Pentium 2. 300MHz. 64 MB RAM. TNT1 
graphics cards to Pentium 4. 1.7 GHz. 2 
GB storage. GeForce 4 graphics cards 
DEVELOPMENT SOFTWARE: MS Visual 
Studio 6. Source Safe. 3DS MAX Z^.0. 

Photoshop 

NOTABLE TECHNOLOGIES: Granny 

Bink 

PROJECT SIZE: 1 .500.000 lines of code 




for something different. At the same 
time, removal or alteration of any exist- 
ing feature will be met with ranting e- 
mails, forum petitions, and overturned 
cars in your parking lot, so this is also 
the time when finding out that preserv- 
ing everything the old games had 
becomes vital. The engine and tools you 
developed for the first game and 
advanced in the second are behind the 
technical curve by this time, so now you 
need to add developing and learning 
new ones to the to-do list. And, at some 
point, you're going to get a visit from a 
graduate of the this-trend-will-continue- 
forever school of projection who, armed 
with charts showing that title One 
moved a million copies and Two moved 
3 million, will tell you Three should 
move 9 million copies. 

This is where the design team was at 
the start of Age of Mythology. The big 
question that haunted us was: Wow, 
what are we going to do to top Age of 
Kings? 

Ensemble Studios' projects are ambi- 
tious, and we ratchet up the ambition 
with each new project. As the scope of 
the project grew, the size of the team 
grew. We were developing a new engine 
and a new multiplayer online service at 
the same time that we were developing a 
new game, a game in which we wanted 
to incorporate new features, such as God 
Powers and myth units, and a more 
ambitious single-player campaign. 

Rather than restate the all-too-com- 
mon problems of having more ambition 
than resources, of having marketing 
push for content before it's ready, and 
of having personnel problems every 
company goes through from time to 
time, we find it more useful to focus on 
design aspects in this article. Designers 
are Ensemble's vision-bearers, but we 
don't get to just ram our ideas down 
everyone else's throats (as attractive as 
that power sounds at times). The 
designers must keep the project in 
scope, keep the artists and program- 
mers from killing each other, and make 
sure feedback is heard without devolv- 
ing the game into a design-by-commit- 
tee project. 



What Went Right 

1 Iteration. Ensemble's basic 
# design process is to get the game 
playable early and then tweak it until 
it's fun. This applied to virtually every 
feature in the game. Some features 
changed a million times, and we were 
willing to abandon things that just did- 
n't work, even when it was painful. 

Age of Mythology's God Power 
feature is a good example of this 
process in action. On paper, our initial 
concept of God Powers and Heroes 
sounded good: Heroes would have but- 
tons on the interface to target God 
Powers wherever the selected Hero hap- 
pened to be — simple enough. 

Unfortunately, when we got the fea- 
ture in the game and started playing 
with it, it was awful. Having to have a 
Hero in the place where you wanted a 
God Power devolved all combat tactics 
to selecting all your units and clicking 
on the enemy hero. This led to Heroes 
constantly getting killed, prompting 
comments like "The Heroes don't feel 
heroic." Additionally, with all God 
Powers targeted with your Hero, if you 
called down a meteor, it would land on 
his hand. It didn't damage him but it 
didn't look good. 

We tried a new model where the 
Heroes built "lightning rods" for the 
God Powers (so players could kill some- 
thing other than enemy Heroes to stop 
an opponent's God Power, and so that 
Heroes could get out of the way of their 
own God Powers). This wasn't fun. We 
tried another model where you could buy 
all of the God Powers with resources, 
like most everything else in the game. 
This wasn't fun. We tried a dozen more 
models and variants. 

Finally, after a lot of trial and error, 
we hit on the model we shipped with. 
Heroes were divorced from God Powers 
and made the thing used to kill myth 
units (which feels decidedly heroic). 
God Powers were moved to the main 
interface, and we made them single-use 
only, which made them feel large and 
important and kept them from landing 
atop Heroes at every use. 
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Units were first conceptualized to make sure that they both fit with the 
common art style, and also could be easily discerned from similar ones 
in the game. 

Because God Powers were so important to the vision of the 
game, we couldn't just yank them from the title after the sixth 
or seventh different model didn't work. Instead, we just con- 
tinued to try different systems, brainstorming and then imple- 
menting models. Because a new approach often required new 
code and new art before it could be evaluated, we ended up 
throwing a lot of work away to achieve our end result. But 
we did achieve an end result we're very happy with. Ours is 
emphatically not an efficient process, but it continues to work 
for us. 

2 Everyone play-tests. It's amazing how many devel- 
# opers rely on outside testers to tell them if the game is 
fun or not. Outside feedback is vital in the later stages of a 
project, but if your entire game is designed by polling the fans 
or beta testers, you end up with a mushy game with no 
vision. At Ensemble, everyone play-tests the game at least 
once a week. This strategy keeps the team bought in to the 
game that's being developed. There are mandatory, assigned 
play-test times in the morning and multiple pickup games in 
the afternoons or evening. 

We have found that these play-tests are instrumental in keep- 
ing the team informed on the state of the project, giving them 
ownership of the process, making sure bugs don't slip through 
the cracks, and figuring out when the gameplay is fun enough to 
ship. The earlier implementation of God Powers described in the 
previous section made sense until it got out in front of our co- 
workers, at which time a mob brandishing torches and pitch- 
forks strolled into our office. If the designers had relied solely 
on our own instinct about the model, we likely would have 
shipped with it. 



Ensemble Studios worked hard to capture the building detail that was a 
hallmark of Age of Empires in the new 3D engine. 

5 Small meetings. For Age of Empires and to a lesser 
# extent Age of Kings, we kept the entire team involved 
in the high-level design. In one particularly long meeting for 
Age of Kings we tried, as a company, to come up with a 
design for herd animals. Past a certain number of attendees, it 
became unmanageable to go around the room even once. So, 
as these meetings got longer, we tried to keep focus by includ- 
ing the various department leads and trusting them to relay 
the feedback of everyone on their respective teams. However, 
in a project the size of Age of Mythology, even the leads' 
meetings could have a dozen attendees, making it harder to 
reach a consensus on any of the issues. 

Eventually we refocused the leads' meetings on task manage- 
ment and progress reports and implemented a new series of 
meetings for design brainstorming with a core group of only 
four to five people, half of them designers. Features, such as the 
list of civilization bonuses, myth unit abilities, and God 
Powers, were all compiled in these meetings. When necessary, 
we took these meetings offsite to make sure we could get our 
business done without distractions. We found that e-mail was- 
n't efficient enough, and as busy as everyone was, impromptu 
meetings weren't always possible. We had to be formal about 
scheduling these conferences, which we ended up arbitrarily 
calling "small pets" (after "pet features," since we needed a 
name that didn't sound Hke we were excluding anyone). 
Because it was important to our process that everyone have a 
chance to give feedback, we would announce the decisions 
made in "small pets" meetings to the company at large. We 
heard people's concerns and ideas, incorporated any changes 
we thought necessary, and then implemented the design into the 
game. Everyone still had a voice, but ultimately we couldn't 
rely on a large group to come up with design implementations 
as fast as we needed them. 
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4 Data-driven tools. Developing data- 
# driven tools early in the process was a 
strategy that really paid off for Age of 
Mythology. It took a lot of programmer time 
away at the start of the project, when we were all 
anxious to begin playing the game, but the 
resource hit paid for itself when designers 
could implement new content without 
having to wake up the programmers 
all the time. For example, although we 
targeted 36 unique God Powers, some of 
these were implemented in similar ways behind the 
scenes. Once the programmers had implemented a 
God Power to switch units, we could turn enemy 
soldiers into pigs, or allied Pharaohs into the Son 
of Osiris, all through data. 

There is, however, a potential downside 
to spending so much effort on tools. 
For one, instead of working on high 
er-visibility game features, program- 
mers spend their time on tools that 
players may not see. Second, you might 
be trading programmer time for designer time. 
Near the end of the project, the design team had 
all the tools they needed to implement 
some features but lacked the time to 
enter the changes. 

5 Focus on campaign. The cam- 
# paigns for Age of Empires and Age of 
Kings were fun but lackluster, largely completed 
by one or two designers. At the beginning of plan 
ning Age of Mythology, we decided that the 
single-player campaign would be one of the 
game's big features on the back of the box. We 
hired several new content designers, invested a 
lot of time in custom animations for the in- 
game cinematics, and made two trips to 
Hollywood to work with professional voice 
actors instead of using local talent or (shud- 
der) our own overacting. 

We had never before attempted an epic, 
character-driven script, and we approached 
the task in epic fashion, appointing a story 
committee to review progress on the script. 
(In retrospect, trying to please so many peo- 
ple so early in the project was more trouble 
than it was worth.) Near the end of the proj- 
ect, the designers working on the campaign, 
often with the artists working on animations 
for the cinematics, met several times a day 
so they could all keep in touch on 
progress. The lead designer docu- 
mented everything, ensuring changes 




were made before testing the various scenarios again. 
It was a tremendous amount of work at the 
end of the project, when we could scarcely 
afford it. But the work paid off, and we 
delivered well-received single-player cam- 
paign. 

What Went Wrong 

^ Design drove too much. Sure, 

■ % the design department had all of 
these fancy tools, but in the end, 
designers ended up doing a lot of the 
work that a programmer might have been 
able to do faster then it took the programmer to 
develop the tool in the first place. We had early 
frustrations when specs didn't pan out as 
intended in the end product, coupled with the 
arrival of new people who had not worked 
with us on a title before. We compensated by 
heaping so much detail into specs that they 
were often not even read. We went so far as to 
I provide descriptions for what artwork should be 
^ associated with the various icons in the scenario 
editor, and the various locations and states for 
those buttons. 

Since all they were doing was connect- 
ing the dots on someone else's feature, 
new employees did not feel empowered. 
As a result of days spent writing things 
such as, "When you click this button, it 
should appear depressed until the user 
releases the mouse button, at which 
time it should revert to looking un- 
depressed; clicking the button in this man- 
ner should cause a sound to occur, the 
sound should be kind of like a twig snap- 
ping...," the design department took up 
drinking in the middle of the afternoon. 
In the future, we plan to keep design 
driving the process, but at a higher level. We will 
trust people at the implementation level to fill 
in the details. 

Scriptwriting nOObs. We knew 

^fa % we wanted a script that had all 
the scope and drama of The Iliad, and we 
knew we wanted characters who could slap each 
other on the back, make fun of each other, and devel- 
op relationships over time. In short, we needed a big 
story with a lot of dialogue. While the designers had 
some writing experience in various forms, 
none of us had ever tackled a script like 
this. We also had not yet figured out how the in-game 
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High-polygon opening cinematics are demanded by the fans. This time around, Ensemble experimented with working with an outside contrac- 
tor Those experiences might make for an entire Postmortem by themselves. 



cinematics would work, or how long we could make them with- 
out boring everyone. 

We had no idea what we were doing. We did it anyway. The 
result was a lot of revisions to satisfy different opinions about 
how a story or characters should work. Everyone had their 
favorite bit character or script fragment that was 
impossible to delete, and deleting anything threat- 
ened to collapse the intricate story line. We eventual 
ly had to take a step back and revise with a much 
smaller group of just two people. In the future we 
will keep early feedback to a smaller group, 
which we hope will get us closer to nailing the 
correct length, number of characters, and plot 
intricacies with fewer revisions. 

Developing this sort of material at both a high 
level of quality and in something resembling an 
efficient manner demands some pain and experi- 
ence that can only be gained by actually doing it. If 
you're planning on doing this sort of project and haven't 
done it before, double your estimates for everything 
related to the project, then halve your plans for the con- 
tent (number of characters, lines of dialogue, number of 
scenarios, number of special art objects, and so on). 

3 Consensus is hard with large groups. 
% Consensus is the basis of the game design 
process at Ensemble. This company philosophy worked 
exceedingly well when there were only a dozen of us. 
Even when we grew to 20 or so people, getting 
everyone in a room (we usually all had lunch 
together) and hashing things out worked well. As 
the size of our team grew, however, it became 
increasingly less efficient to get everyone in a 




room several times a week. Even worse, we stalemated a lot 
more and started to resort to compromises to placate all 
involved, so some of our design decisions began to 
result in bland design-by-committee game models 
("oatmeal design," in our parlance). 

We settled on a strategy where the design 
\ ^ /i^ department would gather everyone's feedback, 

^ ^""^^^ J^^k=^^ mull it over, and then make the call. It was dif- 
ficult changing our mode of communication 
in the middle of the project, and some of the 
squeakier wheels protested that there was a 
design black hole that swallowed up their 
feedback. This prompted us to redouble our 
efforts at documenting and communicating 
changes to the team, but this was an ever- 
widening gyre; for every e-mail you sent out 
explaining a decision, you got five replies that 
disagreed with various points of your logic and 
required a response. Eventually, we got to the 
point where we had to make a decision: the design 
team could either do the work we needed to do to 
and complete the game, or we could explain and 
defend every decision we made. 

We came to think of our larger team size as 
simply a variable — it changes how we go about 
being consensus-based, not whether or not we 
use a consensus-based approach. Either way, we 
were committed to our consensus-based process. 
Our plan at this stage was to formalize what 
The models used for the in-game eventually worked during the latter portions 
cinematics needed to match their of Age of Mythology with our "small 
low-poly equivalents that were pets" meetings. Our new projects are now 
seen during gameplay. built around small, nimble groups with rep- 




50 



february 2003 I game developer 



(postmortem 




One of the goals of Age of Mythology was to design a beautiful, living world, 
players will want to spend time in. 



resentation from all of the disciplines. These groups have the 
ultimate decision-making authority but also the responsibility 
for gathering feedback from the entire team, explaining and 
defending decisions, and building a general consensus. 

4 How different is "different"? The well known, 
% inherent risk of sequels is that you need to keep 
what is popular about earlier products while still offering 
something new to justify the purchase of a new product. The 
Age of Empires games are large and complex, and we knew 
we couldn't take Age of Kings and layer several new game 
features on top of it; we had to pull out some systems and 
change things to make a game that was "different." While 
some of us were (or thought we were) clear on what "differ- 
ent" meant, there were many other definitions floating about. 
For some members of the team, different meant, "Age of 
Kings, but the knights look like Minotaurs." For other team 
members, different meant, "There are no units, and you con- 
trol the game with your mind." When a new feature didn't 
work right away, the differences of opinion led to a lot of 
pressure to revert to the tried-and-true. 

For example, we went through several variations of our pop- 
ulation model. Earlier implementations lacked houses, which 
for some of the team was just too great a departure. The team 
quickly split into two camps, one that argued for even more 
change in the gameplay, and another that was scared that we 
were moving too far from the game our fans loved and expect- 
ed. The fans are not particularly forgiving in this respect, and 
once the game was out, they applauded some of the new fea- 
tures while protesting about even the smallest features that 
were removed, such as choosing your player color. 

Ultimately, there is no ideal solution to the problem of 
defining what is different; games today are too complex to be 
fully defined by a vision statement, so there will always be 
some degree of opinion to factor in. We plan to try to miti- 
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gate these disagreements in the future by attempting to answer 
the big questions such as "How different?" early on, and then 
keeping these guidelines in front of the team for the duration 
of the project. 

5 Unfinished tools. Because we were dealing with a 
# new engine and there was no shared code from our 
previous titles, we made the right decision to reserve a lot of 
time early on to develop tools. Unfortunately, since the tools 
were for internal use only, it was easy to move people off of 
those tasks when other problems came up. Several tools were 
never completely finished, and the customers for those tools 
(typically designers) waited up until the final days of the devel- 
opment cycle to see if improvements of incomplete features 
could be added. While waiting for the tool, we hacked a lot of 
content in place, figuring that it was better to do some work 
than sit idle. A good example was the AI for computer oppo- 
nents in scenarios, which came online very late, after the 
designers had hacked in fake AI using scenario triggers. This 
kind of work was difficult to unhack and left us with less time 
to iterate than we would have liked. 

For the future, we (like everyone else in the game business) 
need to remember the value of tools and not skimp on their 
development time. We additionally need to pay particular atten- 
tion to those tools that might ship with the game, such as the 
scenario editor, which was never completed to our satisfaction. 

Here to Four 




ihe good and bad of getting there aside, the end product of 
all this is our Three, Age of Mythology. Everyone at 



Ensemble Studios is immensely proud to have contributed to 
this game and we're now looking forward to the opportunity to 
figure out what type of beast Four will be. 

At this early stage, we only have one question on the board: 
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Narrative 
Games: Finding 
Another Side 
to the Story 



As developers, we place a dispropor- 
tionate stake of our medium's identity in 
character-based narrative games. These 
games give us something that we can't 
get from the intellectual beta-wave exercise 
of puzzle games or the adrenaline-pumping simulation of 
sports games. While puzzle and sports games represent a hefty 
chunk of game sales and game players, you seldom see a polygo- 
nal quarterback, much less a falling brick, on a magazine cover. 
We want to reach players emotionally in the best way we know 
how; because stories holds a privileged place in our culture — in 
all cultures, in fact — we use these games to represent our craft 
to the outside world. As humans, we use stories to make sense of 
the world, and narrative games are how we achieve that goal in 
our medium. 

If we don't make them relevant to wider audiences by 
increasing their variety and complexity, narrative games will 
ultimately hamper the evolution of games themselves. We must 
expand beyond the classic hero story to get these games past 
the status of geek recreation. It's not going to be easy, or pretty, 
but it's what we'll have to do if we want the game industry to 
grow up and achieve mainstream recognition as a form of art 
and human expression. 

Console publishers and developers have long known that the 
majority of the potential game-buying population doesn't give a 
damn that your game has dynamic LOD, bump-mapped decals, 
and pushes 1.5 trillion multi-pass lit polygons per second. If we 
want a larger audience, we need to shift some focus from the 
visual aspects of game technology and focus on innovations in 
player experiences. 

To accomplish such a shift in narrative games, we need to 
innovate on a number of different fronts: 

Narrative variety. Most story games are comparable to super- 
hero comic books in terms of audience and themes. But why? 
Why not explore more varied subject matter? The majority of 
superhero comics and narrative games give us a chance to play 
with power. But that's not the only story there is to tell about 
being alive. We can innovate through our design and writing to 
explore other facets of existence; we can invent situations and 




stories that a 
player wants to 
experience, even if 

they don't fulfill these obvious power fantasies. 

This kind of innovation poses a bigger challenge than it 
sounds. Hero narratives depend on the triumph of the protago- 
nist. Since we embody the story's protagonist rather than simply 
watching the story unfold, such games leave no room for 
tragedy or failure. Failure can be an effective emotional experi- 
ence as a bystander, but as long as we have choice, we do not 
naturally choose to fail. We don't mind empathizing with a trag- 
ic character if we see the machinations of the universe working 
their ruin, beyond our control, but we can't stand to be that 
person ourselves and be powerless to prevent it. So we need new 
story mechanics that either allow the player to fail and still be 
satisfied, or other contexts for success that don't depend on an 
endless string of worlds-in-peril that only we can save. 

Multiple fully realized characters. Most narrative games are plot 
driven, with no attention given to character subtlety. But this 
doesn't have to remain the case. Some games are already blazing 
compelling trails in this arena. For example. Seaman integrated 
the intimacy of a spoken interface with a nonheroic personal 
story arc. Player achievement in Seaman was on a much smaller 
scale but was as meaningful as saving the world. The day I acci- 
dentally killed my carefully nurtured two-month-old Seaman was 
probably the most emotionally charged moment I've had playing 
a game. On a technical level, until we have simulated personali- 

continued on page 63 
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continued from page 64 

ties complete with nonverbal communica- 
tion and speech recognition, we at least 
need more robust AIs that can make real- 
istic personal decisions in a wide variety 
of scenarios beyond simple fight-or-flight. 

Interface innovation. Button and 
thumbstick controllers are especially 
good for fighting things but not so great 
at other interactions with anthropomor- 
phic characters. Interface innovations in 
speech and face/gesture recognition, and 
the use of input methods such as music 
and text, all possess untapped potential 
to elevate and vary our emotional experi- 
ences in games. 

Emotional buy-in. What makes us 
care? The size of the stakes? Not neces- 
sarily. What's really important is how 
much a given situation or problem 
relates to us personally. Everyone agrees 
that if "the universe" or "good" as we 
know it is destroyed, the situation 
would certainly be personally relevant. 
But smaller stakes can seem equally 
important if they are made sufficiently 
personal. One way to achieve this per- 
sonal relevance is through a direct 
responsibility for another single crea- 
ture. Seaman and earlier, simpler sim 
creatures were examples of this, and 
other recent games have successfully 
used this formula, such as Black & 
White and ICO. More importantly, per- 
sonalizing the responsibility means that 



player responsibility becomes a facet of 
gameplay. In Ico you must actively keep 
Princess Yorda with you by pulling or 
coaxing her forward, and defend her 
from the constant threat of capture. 

Design for player expression. As world 
builders, we can give the players tools 
and settings to inject themselves into the 
story, supporting a broader freedom 
within the constraints of the fictional set- 
ting. In Grand Theft Auto 3, the best 
example to date of this kind of richly 
developed game world, players interact 
with the game world to write their own 
short story, while playing out the larger 
narrative. More often than not, it's those 
player-written stories that make the game 
memorable and generate excitement. 
That's why many players spurned 
GTAS's story mode entirely in favor of 
the open-ended play mode. To make bet- 
ter narrative games, we need to incorpo- 
rate the lessons of systemic gameplay and 
integrate that play style into fiction arcs 
that aren't so easily discarded. 

Development processes that encourage 
innovation. Games with characters and 
narrative are almost universally expen- 
sive. It's no coincidence so many indie 
games are puzzle games, card games, and 
space flight sims. Creating living, walk- 
ing, talking beings is incredibly labor 
intensive. Large teams can saddle such 
risk because the potentials are large 
enough and because the genre is inher- 



ently appealing to established developers. 
Publishers in turn like the fact that recog- 
nizable characters help sell games. But 
indie developers don't have the same 
resources and infrastructure to make rev- 
olutionary narrative games. Mods offer 
some potential, but availability of better 
and cheaper tools for enabling deep char- 
acter development will lead to more 
innovation, sooner. 

For years we've survived on easy inter- 
activity, and what I'm proposing here is 
not the easy stuff. But our medium will 
not expand until we make more effort to 
tackle the hard and messy problems. Not 
all games made with more complicated 
technology are going to be masterpieces 
of the form — in fact they most certainly 
won't be, initially. The biggest ground- 
breakers should try first to entertain. 
Mass appeal nabs publishers and others 
to fund projects; risk can be incremental, 
and amortized. Little by little, our cre- 
ative and artistic landscape will grow; 
only then will our Anna Kareninas and 
Citizen Kanes emerge. 



H£ATH£R K£LL£y I Heather is a 
designer on Thief 3 at Ion Storm Austin. 
She has a master's degree in radio-TV-film 
from the University of Texas and has con- 
tributed production and design work to 
three published titles during her first five 
years in the industry. You can excoriate her 
at hkelley@ionstorm.com. 
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